- Users - oVirt List Archives

Deploy Hosted Engine with PowerFlex (formerly ScaleIO) storage
by twseagulls.kmj＠gmail.com 04 Nov '21

04 Nov '21

Hi This is the first time I have posted a question on here. I am attempting to deploy a Self Hosted Engine with RHV 4.4.8, RHEL 8.4 using a PowerFlex (ScaleIO) volume. I have done this several times in the past with oVirt 4.3.x and 4.4.? but for some reason on this occasion I am hitting a problem. I think I might know what it is but I don't know how to fix it. The deployment appears to go fine up until the point where the question is asked about which storage device I want the HE copied to, I select Fibre Channel but unfortunately this fails and does not find any suitable devices - I know that PowerFlex is not technically FC but the devices are recognised by multipathd and have always worked previously (I was instrumental in getting the udev rules changed in the PowerFlex 3.6 version to ensure the devices could be recognised by multipathd, whereas previously it had required a udev rules edit). The device I am trying to use is this: # multipath -v2 -l 1abc8aad74a6630f-c4c045df00000000 dm-2 ##,## size=120G features='1 queue_if_no_path' hwhandler='0' wp=rw `-+- policy='service-time 0' prio=0 status=active `- #:#:#:# scinia 252:0 active undef running I can see in the log that the device is being partially discovered but it seems that a 'vendor_id' is wanted and this is something that udev does not report for a PowerFlex device. 2021-11-02 07:07:10,057+0000 INFO otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:112 TASK [ovirt.ovirt.hosted_engine_setup : Get Fibre Channel LUNs] 2021-11-02 07:07:10,960+0000 INFO otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:112 ok: [localhost] 2021-11-02 07:07:11,261+0000 DEBUG otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:106 PLAY RECAP [localhost] : ok: 5 changed: 0 unreachable: 0 skipped: 0 failed: 0 2021-11-02 07:07:11,362+0000 DEBUG otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils.run:223 ansible-playbook rc: 0 2021-11-02 07:07:11,362+0000 DEBUG otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils.run:230 ansible-playbook stdout: 2021-11-02 07:07:11,362+0000 DEBUG otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils.run:233 ansible-playbook stderr: 2021-11-02 07:07:11,362+0000 DEBUG otopi.plugins.gr_he_ansiblesetup.core.storage_domain storage_domain._query_fc_lunid:379 {'otopi_fc_devices': {'changed': False, 'ovirt_host_storages': [{'href': '/ovirt-engine/api/hosts/80308d4a-ef91-40fd-8ee e-60c8314b7e13/storage/19eadf533875920f-46da4fac00000000', 'id': '19eadf533875920f-46da4fac00000000', 'host': {'href': '/ovirt-engine/api/hosts/80308d4a-ef91-40fd-8eee-60c8314b7e13', 'id': '80308d4a-ef91-40fd-8eee-60c8314b7e13'}, 'logical_unit s': [{'discard_max_size': 1048576, 'discard_zeroes_data': False, 'id': '19eadf533875920f-46da4fac00000000', 'lun_mapping': 0, 'paths': 1, 'size': 111669149696, 'status': 'free'}], 'type': 'fcp'}], 'invocation': {'module_args': {'host': 'pfxhci 14.hci.spoc', 'fcp': {'lun_id': -1}, 'fetch_nested': False, 'nested_attributes': [], 'follows': [], 'iscsi': None}}, '_ansible_no_log': False}, 'ansible-playbook_rc': 0} 2021-11-02 07:07:11,362+0000 DEBUG otopi.plugins.gr_he_ansiblesetup.core.storage_domain storage_domain._select_lun:398 [{'href': '/ovirt-engine/api/hosts/80308d4a-ef91-40fd-8eee-60c8314b7e13/storage/19eadf533875920f-46da4fac00000000', 'id': '1 9eadf533875920f-46da4fac00000000', 'host': {'href': '/ovirt-engine/api/hosts/80308d4a-ef91-40fd-8eee-60c8314b7e13', 'id': '80308d4a-ef91-40fd-8eee-60c8314b7e13'}, 'logical_units': [{'discard_max_size': 1048576, 'discard_zeroes_data': False, 'i d': '19eadf533875920f-46da4fac00000000', 'lun_mapping': 0, 'paths': 1, 'size': 111669149696, 'status': 'free'}], 'type': 'fcp'}] 2021-11-02 07:07:11,362+0000 DEBUG otopi.plugins.gr_he_ansiblesetup.core.storage_domain storage_domain._select_lun:407 [{'href': '/ovirt-engine/api/hosts/80308d4a-ef91-40fd-8eee-60c8314b7e13/storage/19eadf533875920f-46da4fac00000000', 'id': '1 9eadf533875920f-46da4fac00000000', 'host': {'href': '/ovirt-engine/api/hosts/80308d4a-ef91-40fd-8eee-60c8314b7e13', 'id': '80308d4a-ef91-40fd-8eee-60c8314b7e13'}, 'logical_units': [{'discard_max_size': 1048576, 'discard_zeroes_data': False, 'i d': '19eadf533875920f-46da4fac00000000', 'lun_mapping': 0, 'paths': 1, 'size': 111669149696, 'status': 'free'}], 'type': 'fcp'}] 2021-11-02 07:07:11,362+0000 DEBUG otopi.context context._executeMethod:145 method exception Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/otopi/context.py", line 132, in _executeMethod method['method']() File "/usr/share/ovirt-hosted-engine-setup/scripts/../plugins/gr-he-ansiblesetup/core/storage_domain.py", line 738, in _closeup lun = self._query_fc_lunid() File "/usr/share/ovirt-hosted-engine-setup/scripts/../plugins/gr-he-ansiblesetup/core/storage_domain.py", line 395, in _query_fc_lunid return self._select_lun(available_luns) File "/usr/share/ovirt-hosted-engine-setup/scripts/../plugins/gr-he-ansiblesetup/core/storage_domain.py", line 418, in _select_lun 'vendorID': entry['logical_units'][0]['vendor_id'], KeyError: 'vendor_id' 2021-11-02 07:07:11,364+0000 ERROR otopi.context context._executeMethod:154 Failed to execute stage 'Closing up': 'vendor_id' 2021-11-02 07:07:11,364+0000 DEBUG otopi.context context.dumpEnvironment:765 ENVIRONMENT DUMP - BEGIN 2021-11-02 07:07:11,364+0000 DEBUG otopi.context context.dumpEnvironment:775 ENV BASE/error=bool:'True' 2021-11-02 07:07:11,365+0000 DEBUG otopi.context context.dumpEnvironment:775 ENV BASE/exceptionInfo=list:'[(<class 'KeyError'>, KeyError('vendor_id',), <traceback object at 0x7ff0f4e6da88>)]' 2021-11-02 07:07:11,365+0000 DEBUG otopi.context context.dumpEnvironment:775 ENV QUESTION/1/OVEHOSTED_STORAGE_DOMAIN_TYPE=str:'fc' Is there any way I can edit something to prevent this vendor_id being required? As I said, this has worked previously so I can only assume something has been added that now checks this vendor_id Many thanks in advance

3 2

Re: Issue upgrading VDSM in 4.4.9
by Michal Skrivanek 04 Nov '21

04 Nov '21

Hi Thomas, > On 4. 11. 2021, at 0:40, Thomas Simmons <twsnnva(a)gmail.com> wrote: > > Hello Michal, > Yes was running official RHEL 8.4 on my hosts and have also tried with Rocky. Unfortunately I've already started running into broken dependencies when using the CentOS Stream Advanced Virtualization repos with RHEL. Since oVirt is now targeting Stream and packages are being pushed there, are RHEL and other EL8 clones not going to be supported by oVirt? Thank you. They are, and will be, supported, but it's lagging a bit behind Stream. The exact lag depends on how far are we from the next minor version. 4.4.9 will work on 8.5, there will be RHEL 8.5 and RHEL clones 8.5 soon, but there's not going to be CentOS 8.5, considering there's <2 months until CentOS EOL. So..for oVirt 4.4.9 you can say it's supported only on Stream. And It will be supported very soon on RHEL/clone. That said it will be probably a bit shaky once Stream 9 gets more traction. We will try to move to it whenever it starts working. And for that time until RHEL 9 releases there might be again some issues with RHELs. Thanks, michal > > On Mon, Nov 1, 2021 at 2:52 AM Michal Skrivanek <michal.skrivanek(a)redhat.com <mailto:michal.skrivanek@redhat.com>> wrote: > > > > On 31. 10. 2021, at 2:02, Thomas Simmons <twsnnva(a)gmail.com <mailto:twsnnva@gmail.com>> wrote: > > > > Hello, > > > > I am running into the same issue while attempting a new install of oVirt 4.4 to replace my hyperconverged 4.3 cluster. I am running into the issue on one of the inital steps (yum/dnf install cockpit-ovirt-dashboard vdsm-gluster ovirt-host). After some digging, I found that the version of libvirt that it's looking for (libvirt >= 7.6.0-2) is not in the CentOS 8 Advanced Virt repo, but is only in the CentOS Stream Advanced Virt repo. > > > > You can see here that libvirt 7.0.0-14.1 is the latest available in the CentOS 8 Advanced Virt repo: > > > > http://mirror.centos.org/centos/8/virt/x86_64/advanced-virtualization/Packa… <http://mirror.centos.org/centos/8/virt/x86_64/advanced-virtualization/Packa…> > > > > However, the newer libvirt 7.6.0-2 is available in the 8-stream repo: > > > > http://mirror.centos.org/centos/8-stream/virt/x86_64/advancedvirt-common/Pa… <http://mirror.centos.org/centos/8-stream/virt/x86_64/advancedvirt-common/Pa…> > > > > I don't know if there will be any ramifications down the road (I'm hoping there will not be since Stream tracks just behind the next EL point release), however I was able to get past the error by adding the 8-stream Advanced Virt repo to my systems by creating the repo file below. It would be nice if a developer could respond and advise if this is a "safe" solution, or if this is a known problem that they expect to address? > > Hi, > qemu/libvirt packages are now being pushed to Stream, CentOS is supposedly EOL in 2 months. Currently there's not much of a difference and if packages are installed happily then it likely works just fine, but with the upcoming RHEL 8.5 release it is unlikely CentOS would be updated to 8.5, so I'm afraid CentOS based systems won't last for too long. It would be best to move to Stream entirely, or use ovirt-node (as a snapshot of packages that work), or move to RHEL or RHEL clones. > > Thanks, > michal > > > > > # /etc/yum/repos.d/ovirt-4.4-stream-advanced-virt.repo > > [ovirt-centos-stream-advanced-virtualization] > > name=Advanced Virtualization CentOS Stream testing packages for $basearch > > baseurl=https://buildlogs.centos.org/centos/8-stream/virt/$basearch/advance… <https://buildlogs.centos.org/centos/8-stream/virt/$basearch/advancedvirt-co…> > > enabled=1 > > gpgcheck=0 > > module_hotfixes=1 > > _______________________________________________ > > Users mailing list -- users(a)ovirt.org <mailto:users@ovirt.org> > > To unsubscribe send an email to users-leave(a)ovirt.org <mailto:users-leave@ovirt.org> > > Privacy Statement: https://www.ovirt.org/privacy-policy.html <https://www.ovirt.org/privacy-policy.html> > > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> > > List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/FNK5TJW7RWGUI… <https://lists.ovirt.org/archives/list/users@ovirt.org/message/FNK5TJW7RWGUI…> >

1 0

add users to group
by Nathanaël Blanchet 04 Nov '21

04 Nov '21

Hello, The only way I found to add users to group is : ovirt-aaa-jdbc-tool group-manage useradd /|group-name|/ --user=/|username|/ I didn't find any way to do such a thing neither with the webui, neither with ansible module ovirt_group or ovirt_user. Thanks for advices. -- Nathanaël Blanchet Supervision réseau SIRE 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet(a)abes.fr

1 1

export to export domain concurrency
by Gianluca Cecchi 04 Nov '21

04 Nov '21

Hello, the export to export domain task is managed asynchronously. Does it support concurrency, so that I can export more VMs at the same time to the same export domain? If not by default, is there a parameter to enable it? The need would be on 4.4.7/4.4.8 based environments Thanks, Gianluca

2 2

Host moved to Non-Operational state as host CPU type is not supported in this cluster compatibility version or is not supported at all
by sekevgeniyig＠gmail.com 04 Nov '21

04 Nov '21

Hi, can you help me please. After installing the node, the host gets the status of blah blah, node and engine is installed on ec2 instances

2 3

Failed to delete snapshot
by ivohccarvalho＠gmail.com 03 Nov '21

03 Nov '21

Hello all. We use vprotect to make snapshot backups of our vm's. This VM, let's call it OVIRTVM, has it's disks created as thin. A full snapshot is created daily on sunday and the daily ones are incremental. After the backup vprotect tries to delete the snapshot and almost always fails with the error: "Failed to delete snapshot 'vProtect 2021-10-25 22:30:17.641654' for VM 'OVIRTVM'." From engine.log can't get much more information: 2021-10-26 22:39:02,510+01 INFO [org.ovirt.engine.core.sso.utils.AuthenticationUtils] (default task-511666) [] User admin@internal successfully logged in with scopes: ovirt-app-api ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search ovirt-ext=token-info:validate ovirt-ext=token:password-access 2021-10-26 22:39:02,558+01 ERROR [org.ovirt.engine.core.bll.snapshots.RemoveSnapshotCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-15) [666e0f97-8b02-4b1e-80d4-2a640dd28d90] Ending command 'org.ovirt.engine.core.bll.snapshots.RemoveSnapshotCommand' with failure. 2021-10-26 22:39:02,595+01 INFO [org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-511666) [1a9981] Running command: CreateUserSessionCommand internal: false. 2021-10-26 22:39:02,630+01 INFO [org.ovirt.engine.core.sso.utils.AuthenticationUtils] (default task-511612) [] User admin@internal successfully logged in with scopes: ovirt-app-api ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search ovirt-ext=token-info:validate ovirt-ext=token:password-access 2021-10-26 22:39:02,674+01 INFO [org.ovirt.engine.core.sso.utils.AuthenticationUtils] (default task-511669) [] User admin@internal successfully logged in with scopes: ovirt-app-api ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search ovirt-ext=token-info:validate ovirt-ext=token:password-access 2021-10-26 22:39:02,729+01 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engineScheduled-Thread-15) [666e0f97-8b02-4b1e-80d4-2a640dd28d90] EVENT_ID: USER_REMOVE_SNAPSHOT_FINISHED_FAILURE(357), Failed to delete snapshot 'vProtect 2021-10-25 22:30:17.641654' for VM 'OVIRTVM'. 2021-10-26 22:39:02,739+01 INFO [org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-511675) [55891f0c] Running command: CreateUserSessionCommand internal: false. 2021-10-26 22:39:02,755+01 INFO [org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-511660) [7895798d] Running command: CreateUserSessionCommand internal: false. What else should I be looking for? Thanks in advance!

3 6

is disk reduce command while VM is active after snapshot deletion save?
by christian.peater＠gmx.de 03 Nov '21

03 Nov '21

When creating a snapshot, the volume gets two lv extents (2GB) . But after deleting the snapshot, the extents are kept and with every Snapshot creation the volume size increases. This is really annoying, especially when using snapshot for nightly backup. we are using oVirt 4.3.10 and we can't upgrade to 4.4 I have read that to shrink the volume the disk reduce command is what helps here, but the rest api documentation says, that this is only applicable while vm is not running. crazy as i am, i have called the reduce command while the vm was running, and it seemed to work. the volume has shrunk and the vm didn't crash. But is it save to do so? and why isn't the reduce command is called after deletion of a snapshot?

3 3

Importing default Grafana dashboards?
by Chris Adams 03 Nov '21

03 Nov '21

I upgraded a cluster to 4.4 (so really, reinstalled the engine with a backup and reinstalled all the hosts). I see the Monitoring Portal link to Grafana, but when I log in, there are no dashboards. Did I miss a step to import the default dashboard set? Is there a quick-and-easy way to do that? I've only barely poked at Grafana before, so not really sure what to do. -- Chris Adams <cma(a)cmadams.net>

1 1

Re: Some errors on the grafana dashboard
by Aviv Litman 03 Nov '21

03 Nov '21

Hi Tommy, You can apply the patches by changing the relevant files in engine and dwh and run 'engine-setup' or 'engine-setup --offline' . Steps: 1. connect to your engine machine 2. vi /usr/share/ovirt-engine/dbscripts/create_dwh_views.sql : add the new line as described in the patch: https://gerrit.ovirt.org/#/c/ovirt-engine/+/114565/4/packaging/dbscripts/cr… . 3. connect to your dwh machine (if the engine and dwh are on the same machine then all files are in the same machine) 4. create or edit the files in the patch: https://gerrit.ovirt.org/#/c/ovirt-dwh/+/114568/, note that for you files named 4_4 should be named 4_3 You can find the file's location with this command: find / -name *create_views_4_3.sql* 5. run engine-setup, or engine-setup --offline Let me know how it goes! Thanks, Aviv On Mon, Nov 1, 2021 at 9:42 AM Tommy Sway <sz_cuitao(a)163.com> wrote: > But how to apply the patches? > > > > Is some docs can guide me how to apply? > > > > Thanks. > > > > > > > > > > *From:* Aviv Litman <alitman(a)redhat.com> > *Sent:* Sunday, October 3, 2021 10:08 PM > *To:* Tommy Sway <sz_cuitao(a)163.com> > *Subject:* Re: Some errors on the grafana dashboard > > > > Important note: do not to change the minimal version part in dwh > ovirt-engine-dwh.spec.in file. > > > > On Sun, Oct 3, 2021 at 4:50 PM Aviv Litman <alitman(a)redhat.com> wrote: > > Hi Tommy, > You can try to implement the patches I shared manually by changing the > relevant files in engine and dwh and run engine-setup. > > Let me know if you have any questions. > > Thanks, > Aviv > > > > On Sun, Sep 19, 2021 at 4:56 PM Tommy Sway <sz_cuitao(a)163.com> wrote: > > Thank you! > > > > > > > > > > > > *From:* Aviv Litman <alitman(a)redhat.com> > *Sent:* Sunday, September 19, 2021 3:04 PM > *To:* Tommy Sway <sz_cuitao(a)163.com> > *Subject:* Re: Some errors on the grafana dashboard > > > > Hi Tommy, > There was a bug in the way we calculate hosts CPU: we didn't consider > the count_threads_as_cores option in the calculation. > The count_threads_as_cores column is available only from ovirt-engine > 4.4.6.7 version, and ovirt-dwh 4.4.7. > > Patches: > > ovirt-engine <https://gerrit.ovirt.org/#/c/ovirt-engine/+/114565/> > > ovirt-dwh <https://gerrit.ovirt.org/#/c/ovirt-dwh/+/114568/> > > So you have to update the version to 4.4.7. > I will also add a note in the Blog. > > Feel free to contact me if you have more questions. > > Best, > Aviv > > > > On Tue, Sep 14, 2021 at 11:38 AM Tommy Sway <sz_cuitao(a)163.com> wrote: > > Hello! > > > > I used the JSON file you provided and imported grafana. Before importing, > I replaced the version, because the version of my system is 4.3. > > $ find . -type f -name "*dashboard.json" -exec sed -i -e 's/v4_4_/v4_3_/g' > {} \; > > However, most of the reports are normal, but some reports have similar > errors: > > > > pq: column "count_threads_as_cores" does not exist > > Object > > status:400 > > statusText:"Bad Request" > > data:Object > > results:Object > > message:"pq: column "count_threads_as_cores" does not exist" > > message:"pq: column "count_threads_as_cores" does not exist" > > > > Many of the other reports worked fine, with only a few similar errors. > > Is this caused by version incompatibility? > > After all, 4.4 in the original document was replaced with 4.3 before the > import. > > > > Thank you! > > > > > >

2 3

question about engine deployment success rate
by Henning Sprang 02 Nov '21

02 Nov '21

Hello, I've just inherited a project where we need to bring a prototype of a small Ovirt system (single node or 3 node hyperconverged, with glusterFS on the same machine, a bunch of different VM's ) running in an industrial machine into serial production. This means, we want to build a new 1 or 3 node Ovirt system each day up until 3 times a day. In my tests so far, the failure rate of the Ovirt engine deployment (via the included scripts as well as the web UI) turns out to be pretty high - it's between 40-60%, meaning until we have a running system, we would have to try the installation and/or final engine deployment about 2-4 times until we are successful. So far I could not identify clear error messages that let me tell how to fix the problem. Before going into details of the errors I would like to ask if people deeper into Ovirt would consider this a somewhat normal success rate, or if this indicates we are doing something generally wrong and we should definitely spend a few more hours or maybe days into finding sources of problems. More info about the system and errors * OVirt 4.3.9 (because the prototype was made and verified with that version - would be interesting to know, too, if it's strongly considered to upgrade for more stable installation/deployment) * The errors that appear are changing between the deployment process seeming not to be able to transfer the "LocalHostedEngine" VM to the glusterFS storage to become a "HostedEngine", and the other seems to be when the engine is already up and running, but never being really connected to the Ovirt system, continuously restarting, and also showing XFS filesystem errors in it's dmesg output. Any hints on our chances on getting this solved or requests for more information about the error are welcome - thanks in advance. Henning

2 5