October 2020 - Users - oVirt List Archives

Upgrade from ovirt-node-ng 4.4.1 to 4.4.2 fails with "Local storage domains were found on the same filesystem as / ! Please migrate the data to a new LV before upgrading, or you will lose the VMs"
by gantonjo-ovirt＠yahoo.com 20 Oct '20

20 Oct '20

So, we have a cluster of 3 servers running oVirt Node 4.4.1. Now we are attempting to upgrade it to latest version, 4.4.2, but it fails as shown below. Problem is that the Storage domains listed are all located on an external iSCSI SAN. The Storage Domains were created in another cluster we had (oVirt Node 4.3 based) and detached from the old cluster and imported successfully into the new cluster through the oVirt Management interface. As I understand, oVirt itself has created the mount points under /rhev/data-center/mnt/blockSD/ for each of the iSCSI domains, and as such they are not really storaged domains on the / filesystem. I do believe the solution to the mentioned BugZilla bug has caused a new bug, but I may be wrong. I cannot see what we have done wrong when importing these storage domains to the cluster (well, actually, some were freshly created in this cluster, thus fully managed by oVirt 4.4 manager interface). What can we do to proceed in upgrading the hosts to latest oVirt Node? Dependencies resolved. ============================================================================================================================================================================================================================================================================================================================= Package Architecture Version Repository Size ============================================================================================================================================================================================================================================================================================================================= Upgrading: ovirt-node-ng-image-update noarch 4.4.2-1.el8 ovirt-4.4 782 M replacing ovirt-node-ng-image-update-placeholder.noarch 4.4.1.5-1.el8 Transaction Summary ============================================================================================================================================================================================================================================================================================================================= Upgrade 1 Package Total download size: 782 M Is this ok [y/N]: y Downloading Packages: ovirt-node-ng-image-update-4.4.2-1.el8.noarch.rpm 8.6 MB/s | 782 MB 01:31 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Total 8.6 MB/s | 782 MB 01:31 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Running scriptlet: ovirt-node-ng-image-update-4.4.2-1.el8.noarch 1/3 Local storage domains were found on the same filesystem as / ! Please migrate the data to a new LV before upgrading, or you will lose the VMs See: https://bugzilla.redhat.com/show_bug.cgi?id=1550205#c3 Storage domains were found in: /rhev/data-center/mnt/blockSD/c3df4c98-ca97-4486-a5d4-d0321a0fb801/dom_md /rhev/data-center/mnt/blockSD/90a52746-e0cb-4884-825d-32a9d94710ff/dom_md /rhev/data-center/mnt/blockSD/74673f68-e1fa-46cf-b0ac-a35f05d42a7a/dom_md /rhev/data-center/mnt/blockSD/f5fe00ba-c899-428f-96a2-e8d5e5707905/dom_md /rhev/data-center/mnt/blockSD/5c3d9aff-66a3-4555-a17d-172fbf043505/dom_md /rhev/data-center/mnt/blockSD/4cc6074b-a5f5-4337-a32f-0ace577e5e47/dom_md /rhev/data-center/mnt/blockSD/a7658abd-e605-455e-9253-69d7e59ff50a/dom_md /rhev/data-center/mnt/blockSD/f18e6e5c-124b-4a66-ae98-2088c87de42b/dom_md /rhev/data-center/mnt/blockSD/f431e29b-77cd-4e51-8f7f-dd73543dfce6/dom_md /rhev/data-center/mnt/blockSD/0f53281c-c756-4171-bcd2-8946956ebbd0/dom_md /rhev/data-center/mnt/blockSD/9fad9f9b-c549-4226-9278-51208411b2ac/dom_md /rhev/data-center/mnt/blockSD/c64006e7-e22c-486f-82a5-20d2b9431299/dom_md /rhev/data-center/mnt/blockSD/509de8b4-bc41-40fa-9354-16c24ae16442/dom_md /rhev/data-center/mnt/blockSD/0d57fcd3-4622-41cc-ab23-744b93d175a0/dom_md error: %prein(ovirt-node-ng-image-update-4.4.2-1.el8.noarch) scriptlet failed, exit status 1 Error in PREIN scriptlet in rpm package ovirt-node-ng-image-update Verifying : ovirt-node-ng-image-update-4.4.2-1.el8.noarch 1/3 Verifying : ovirt-node-ng-image-update-4.4.1.5-1.el8.noarch 2/3 Verifying : ovirt-node-ng-image-update-placeholder-4.4.1.5-1.el8.noarch 3/3 Unpersisting: ovirt-node-ng-image-update-4.4.1.5-1.el8.noarch.rpm Unpersisting: ovirt-node-ng-image-update-placeholder-4.4.1.5-1.el8.noarch.rpm Thanks in advance for your good help.

4 9

oVirt Survey Autumn 2020 results
by Sandro Bonazzola 19 Oct '20

19 Oct '20

Thanks to the 79 participants to oVirt Survey Autumn 2020! The survey is now closed and results are publicly available at https://docs.google.com/forms/d/1eMYaCoysPkYt2iHZW2RRO1HmSqsD0phrwSTVYFlqLy… We'll analyze collected data in order to improve oVirt thanks to your feedback. Thanks, -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.* * <https://www.redhat.com/it/forums/emea/italy-track>*

1 0

Enable Gluster Service
by suporte＠logicworks.pt 18 Oct '20

18 Oct '20

Hello, When I Enable Gluster Service on the cluster, de data center goes to invalid state. Any idea why? -- Jose Ferradeira http://www.logicworks.pt

2 1

How to make oVirt + GlusterFS bulletproof
by Jarosław Prokopowski 16 Oct '20

16 Oct '20

Hi Guys, I had a situation 2 times that due to unexpected power outage something went wrong and VMs on glusterfs where not recoverable. Gluster heal did not help and I could not start the VMs any more. Is there a way to make such setup bulletproof? Does it matter which volume type I choose - raw or qcow2? Or thin provision versus reallocated? Any other advise?

5 16

Latest ManagedBlockDevice documentation
by Michael Thomas 15 Oct '20

15 Oct '20

I'm looking for the latest documentation for setting up a Managed Block Device storage domain so that I can move some of my VM images to ceph rbd. I found this: https://ovirt.org/develop/release-management/features/storage/cinderlib-int… ...but it has a big note at the top that it is "...not user documentation and should not be treated as such." The oVirt administration guide[1] does not talk about managed block devices. I've found a few mailing list threads that discuss people setting up a Managed Block Device with ceph, but didn't see any links to documentation steps that folks were following. Is the Managed Block Storage domain a supported feature in oVirt 4.4.2, and if so, where is the documentation for using it? --Mike [1]ovirt.org/documentation/administration_guide/

4 19

How can I Disable console Single Sign On by default
by Riccardo Brunetti 15 Oct '20

15 Oct '20

Dear all. I'm trying to setup an oVirt environment able to provide VMs to a small number of users. I'm just using the "internal" domain and I defined some users and groups using ovirt-aaa-jdbc-tool. Everything seems to work, the users cal log-in into the VM portal and they can create VM. The problem comes out when I try to access the VM console: in order to be able to open the noVNC console, I need to set Disable Single Sign On on the console settings of the VM. But this is only possible using the Administrator portal and I couldn't find a way to do it "as user". How can I allow users to open the noVNC console from the VM portal? Is there a way to set Disable Single Sign On by default? Thanks a lot Riccardo

1 1

Upgrade from 4.3.9 to 4.3.10 leads to sanlock errors
by mschuler＠bsgtech.com 15 Oct '20

15 Oct '20

After upgrading to 4.3.10 from 4.3.9, when doing VM backups after hours, we started to have VMs freeze/pause during nightly backup runs. We expect the increased load exposes the issue. We reverted the hosts back to 4.3.9 and the problem went away, after some testing using a single host on .10 , I am seeing the below error in sanlock.log: 2020-10-14 16:06:12 2939 [5724]: 95bd5893 aio timeout RD 0x7f7f9c0008c0:0x7f7f9c0008d0:0x7f7fa9efb000 ioto 10 to_count 1 2020-10-14 16:06:12 2939 [5724]: s2 delta_renew read timeout 10 sec offset 0 /dev/95bd5893-83d4-42f2-b333-1c65226f1d09/ids 2020-10-14 16:06:12 2939 [5724]: s2 renewal error -202 delta_length 10 last_success 2908 2020-10-14 16:06:14 2941 [5724]: 95bd5893 aio collect RD 0x7f7f9c0008c0:0x7f7f9c0008d0:0x7f7fa9efb000 result 1048576:0 match reap So engine is still at 4.3.10. We also see the error below in messages: Oct 14 16:09:20 HOSTNAME kernel: perf: interrupt took too long (2509 > 2500), lowering kernel.perf_event_max_sample_rate to 79000 I guess my question is two fold, how do I go about troubleshooting this further. Otherwise would it be better/possible to move to 4.4.2 (or 4.4.3 when released.) Do all hosts have to be on 4.3.10, or can the hosts be on 4.3.9 while engine is 4.3.10 to do the migration? Thank you!

1 0

Connection failed
by info＠worldhostess.com 15 Oct '20

15 Oct '20

Messages related to the failure might be found in the journal "journalctl -u cockpit" This is the output node01.xxx.co.za cockpit-tls[8249]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received. Any suggestion will be appreciated as I struggle for days to get oVirt to work and I can see it is still a long way for me to get an operational solution. Henni

2 1

Collectd version downgrade on oVirt engine
by kushagra2agarwal＠gmail.com 15 Oct '20

15 Oct '20

i am trying to downgrade collectd version on oVirt engine from 5.10.0 to 5.8.4 using ansible, but getting error while doing so. Can someone help to fix issue ---------------------- Ansible yml file --- - name: Perform a yum clean command: /usr/bin/yum clean all - name: downgrade collectd version to 5.8.1 yum: name: - collectd-5.8.1-4.el7.x86_64 - collectd-disk-5.8.1-4.el7.x86_64 state: present allow_downgrade: true update_cache: true become: true ----- error {"changed": false, "changes": {"installed": ["collectd-5.8.1-4.el7.x86_64"]}, "msg": "Error: Package: collectd-write_http-5.10.0-2.el7.x86_64 (@ovirt-4.3-centos-opstools)\n Requires: collectd(x86-64) = 5.10.0-2.el7\n Removing: collectd-5.10.0-2.el7.x86_64 (@ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.10.0-2.el7\n Downgraded By: collectd-5.8.1-4.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.1-4.el7\n Available: collectd-5.7.2-1.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.7.2-1.el7\n Available: collectd-5.7.2-3.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.7.2-3.el7\n Available: collectd-5.8.0-2.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.0-2.el7\n Available: collectd-5.8.0-3.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.0-3.el7\n Available: collectd-5.8.0-5.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.0-5.el7\n Available: collectd-5.8.0-6.1.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.0-6.1.el7\n Available: collectd-5.8.1-1.el7.x86_64 (epel)\n collectd(x86-64) = 5.8.1-1.el7\n Available: collectd-5.8.1-2.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.1-2.el7\n Available: collectd-5.8.1-3.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.1-3.el7\n Available: collectd-5.8.1-5.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.1-5.el7\nError: Package: collectd-disk-5.10.0-2.el7.x86_64 (@ovirt-4.3-centos-opstools)\n Requires: collectd(x86-64) = 5.10.0-2.el7\n Removing: collectd-5.10.0-2.el7.x86_64 (@ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.10.0-2.el7\n Downgraded By: collectd-5.8.1-4.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.1-4.el7\n Available: collectd-5.7.2-1.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.7.2-1.el7\n Available: collectd-5.7.2-3.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.7.2-3.el7\n Available: collectd-5.8.0-2.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.0-2.el7\n Available: collectd-5.8.0-3.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.0-3.el7\n Available: collectd-5.8.0-5.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.0-5.el7\n Available: collectd-5.8.0-6.1.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.0-6.1.el7\n Available: collectd-5.8.1-1.el7.x86_64 (epel)\n collectd(x86-64) = 5.8.1-1.el7\n Available: collectd-5.8.1-2.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.1-2.el7\n A ▽ vailable: collectd-5.8.1-3.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.1-3.el7\n Available: collectd-5.8.1-5.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.1-5.el7\nError: Package: collectd-postgresql-5.10.0-2.el7.x86_64 (@ovirt-4.3-centos-opstools)\n Requires: collectd(x86-64) = 5.10.0-2.el7\n Removing: collectd-5.10.0-2.el7.x86_64 (@ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.10.0-2.el7\n Downgraded By: collectd-5.8.1-4.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.1-4.el7\n Available: collectd-5.7.2-1.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.7.2-1.el7\n Available: collectd-5.7.2-3.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.7.2-3.el7\n Available: collectd-5.8.0-2.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.0-2.el7\n Available: collectd-5.8.0-3.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.0-3.el7\n Available: collectd-5.8.0-5.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.0-5.el7\n Available: collectd-5.8.0-6.1.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.0-6.1.el7\n Available: collectd-5.8.1-1.el7.x86_64 (epel)\n collectd(x86-64) = 5.8.1-1.el7\n Available: collectd-5.8.1-2.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.1-2.el7\n Available: collectd-5.8.1-3.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.1-3.el7\n Available: collectd-5.8.1-5.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.1-5.el7\nError: Package: collectd-write_syslog-5.10.0-2.el7.x86_64 (@ovirt-4.3-centos-opstools)\n Requires: collectd(x86-64) = 5.10.0-2.el7\n Removing: collectd-5.10.0-2.el7.x86_64 (@ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.10.0-2.el7\n Downgraded By: collectd-5.8.1-4.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.1-4.el7\n Available: collectd-5.7.2-1.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.7.2-1.el7\n Available: collectd-5.7.2-3.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.7.2-3.el7\n Available: collectd-5.8.0-2.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.0-2.el7\n Available: collectd-5.8.0-3.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.0-3.el7\n Available: collectd-5.8.0-5.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.0-5.el7\n Available: collectd-5.8.0-6.1.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.0-6.1.el7\n Available: collectd-5.8.1-1.el7.x86_64 (epel)\n collectd(x86-64) = 5.8.1-1.el7\n Available: collectd-5.8.1-2.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.1-2.el7\n Available: collectd-5.8.1-3.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.1-3.el7\n Available: collectd-5.8.1-5.el7.x86_64 (ovirt-4.3-centos-opstools)\n collectd(x86-64) = 5.8.1-5.el7\n", "rc": 1, "results": ["Loaded plugins: fastestmirror, versionlock\nLoading mirror speeds from cached hostfile\n updates: mirror.ash.fastserv.com\nResolving Dependencies\n--> Running transaction check\n---> Package collectd.x86_64 0:5.8.1-4.el7 will be a downgrade\n---> Package collectd.x86_64 0:5.10.0-2.el7 will be erased\n--> Finished Dependency Resolution\n You could try using --skip-broken to work around the problem\n You could try running: rpm -Va --nofiles --nodigest\n"]}

2 1

Ovirt Node 4.4.2 install Odroid-H2 64GB eMMC
by franklin.shearer＠gmail.com 15 Oct '20

15 Oct '20

Hi All, I'm trying to install node 4.4.2 on an eMMC card, but when I get to the storage configuration of the installer, it doesn't save the settings (which is automatic configuration) I have chosen and displays failed to save storage configuration. I have deleted all partitions on the card before trying to install and I still get the same error. The only way I can get it to go is select manual configuration with LVM thin provisioning and automatically create. Am I doing something wrong. I can install Centos 8 no issues on this, but not oVirt node 4.4.2.

2 1