- Users - oVirt List Archives

[ANN] oVirt 4.4.7 First Release Candidate is now available for testing
by Lev Veyde 28 May '21

28 May '21

oVirt 4.4.7 First Release Candidate is now available for testing The oVirt Project is pleased to announce the availability of oVirt 4.4.7 First Release Candidate for testing, as of May 27th, 2021. This update is the seventh in a series of stabilization updates to the 4.4 series. How to prevent hosts entering emergency mode after upgrade from oVirt 4.4.1 Note: Upgrading from 4.4.2 GA or later should not require re-doing these steps, if already performed while upgrading from 4.4.1 to 4.4.2 GA. These are only required to be done once. Due to Bug 1837864 <https://bugzilla.redhat.com/show_bug.cgi?id=1837864> - Host enter emergency mode after upgrading to latest build If you have your root file system on a multipath device on your hosts you should be aware that after upgrading from 4.4.1 to 4.4.7 you may get your host entering emergency mode. In order to prevent this be sure to upgrade oVirt Engine first, then on your hosts: 1. Remove the current lvm filter while still on 4.4.1, or in emergency mode (if rebooted). 2. Reboot. 3. Upgrade to 4.4.7 (redeploy in case of already being on 4.4.7). 4. Run vdsm-tool config-lvm-filter to confirm there is a new filter in place. 5. Only if not using oVirt Node: - run "dracut --force --add multipath” to rebuild initramfs with the correct filter configuration 6. Reboot. Documentation - If you want to try oVirt as quickly as possible, follow the instructions on the Download <https://ovirt.org/download/> page. - For complete installation, administration, and usage instructions, see the oVirt Documentation <https://ovirt.org/documentation/>. - For upgrading from a previous version, see the oVirt Upgrade Guide <https://ovirt.org/documentation/upgrade_guide/>. - For a general overview of oVirt, see About oVirt <https://ovirt.org/community/about.html>. Important notes before you try it Please note this is a pre-release build. The oVirt Project makes no guarantees as to its suitability or usefulness. This pre-release must not be used in production. Installation instructions For installation instructions and additional information please refer to: https://ovirt.org/documentation/ This release is available now on x86_64 architecture for: * Red Hat Enterprise Linux 8.4 or similar * CentOS Stream 8 This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: * Red Hat Enterprise Linux 8.4 or similar * CentOS Stream 8 * oVirt Node 4.4 based on CentOS Stream 8 (available for x86_64 only) See the release notes [1] for installation instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available based on CentOS Stream 8 - oVirt Node NG is already available based on CentOS Stream 8 Additional Resources: * Read more about the oVirt 4.4.7 release highlights: http://www.ovirt.org/release/4.4.7/ * Get more oVirt project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] http://www.ovirt.org/release/4.4.7/ [2] http://resources.ovirt.org/pub/ovirt-4.4-pre/iso/ -- Lev Veyde Senior Software Engineer, RHCE | RHCVA | MCITP Red Hat Israel <https://www.redhat.com> lev(a)redhat.com | lveyde(a)redhat.com <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

1 0

unable to login cockpit using root after upgrading to 4.4.6
by dhanaraj.ramesh＠yahoo.com 28 May '21

28 May '21

Hi Team, after upgrading ovirt node from 4.4.5 to 4.4.6, unale to login to the cockpit using root, but could able to login via ssh. please check whether this is considered as bug

13 21

CPU usage question
by David Johnson 28 May '21

28 May '21

Hi everyone, I am slowly working the performance bottlenecks out of my rack, and ran into this puzzling scenario. Ovirt shows CPU usage at over 50%. Windows shows CPU usage between 5 and 15 % The backing store is TrueNAS NFS on a 10 GBit lan. I am seeing just under 1 GBit throughput on the storage network for this operation (create database). Am I reading this correctly that my system is bottlenecking on the CPU used to handle the Windows disk IO over TCP/IP ? Thanks *David Johnson* Screenshot of pertinent metrics: [image: image.png] <https://www.linkedin.com/in/pojoguy/> <https://maxistechnology.com/wp-content/uploads/vcards/vcard-David_Johnson.v…> <https://maxistechnology.com/> *Follow us:* <https://www.linkedin.com/company/maxis-tech-inc/>

2 1

Unable to migrate VMs
by Jayme 27 May '21

27 May '21

I have a three node oVirt 4.4.5 cluster running oVirt node hosts. Storage is mix of GlusterFS and NFS. Everything has been running smoothly, but the other day I noticed many VMs had invalid snapshots. I run a script to export OVA for VMs for backup purposes, exports seemed to have been fine but snapshots failed to delete at the end. I was able to manually delete the snapshots through oVirt admin GUI without any errors/warnings and the VMs have been running fine and can restart them without problems. I thought this problem may be due to snapshot bug which is supposedly fixed in oVirt 4.4.6. I decided to start upgrading cluster to 4.4.6 and am now having a problem with VMs not being able to migrate. When I migrate any VM (doesn't seem to matter which host to and from) the process starts but stops at 0-1%. Eventually after 15-30 minutes or more the tasks are all completed by the VM is not migrated. I am unable to migrate any VMs and as such I cannot place any host in maintenance mode. I've attaching some VDSM logs from source and destination hosts, these were after initiating a migration of a single VM I'm seeing some errors in the logs regarding the migration stalling, but not able to determine why its stalling. 2021-05-27 17:10:22,167+0000 INFO (jsonrpc/4) [api.host] FINISH getAllVmIoTunePolicies return={'status': {'code': 0, 'message': 'Done'}, 'io_tune_policies_dict': {'f8f4e4a1-b565-4663-8962-c8804dbb86fb': {'policy': [], 'current_values': [{'name': 'vda', 'path': '/rhev/data-center/mnt/10.11.0.9:_vmstorage_nvme1n1/bce04425-1d25-4489-bdab-2834a1a57db8/images/38b27cce-c744-4a12-85a3-3af07d386da2/93c1e793-f8cb-42c9-86a6-0e9ce4a6023a', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}]}, '2b87204f-f695-474a-9f08-47b85fcac366': {'policy': [], 'current_values': [{'name': 'sda', 'path': '/rhev/data-center/mnt/10.11.0.9:_vmstorage_nvme0n1/a99cd663-f6d5-42d8-bd7a-ee0b5d068608/images/f2e0c9f3-ab0d-441a-85a6-07a42e78b5a8/848f353e-6787-4e20-ab7b-0541ebd852c6', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}]}, '26332421-54a3-4afc-90e7-551a7e314c80': {'policy': [], 'current_values': [{'name': 'vda', 'path': '/rhev/data-center/mnt/10.11.0.9:_vmstorage_nvme0n1/a99cd663-f6d5-42d8-bd7a-ee0b5d068608/images/b7a785f9-307b-42af-9bbe-23cac884fe97/ed1d027e-a36a-4e6b-9207-119915044e06', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}]}, '60edbd80-dad7-4bf8-8fd1-e138413cf9f6': {'policy': [], 'current_values': [{'name': 'sda', 'path': '/rhev/data-center/mnt/10.11.0.9:_vmstorage_nvme2n1/a7efa448-201b-4453-9bc9-900559b891ca/images/535fcb2e-ece9-4d50-86fe-bf6264d11ae1/6c01a036-8a14-46ba-a4b4-fe4f66a586a3', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}, {'name': 'sdb', 'path': '/rhev/data-center/mnt/10.11.0.9:_vmstorage_nvme2n1/a7efa448-201b-4453-9bc9-900559b891ca/images/1f467fb5-5ea7-42ba-bace-f175c86791b2/cbe8327f-9b7f-442f-a650-6888bb11a674', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}, {'name': 'sdd', 'path': '/rhev/data-center/mnt/10.11.0.9:_vmstorage_nvme2n1/a7efa448-201b-4453-9bc9-900559b891ca/images/c93956d5-c88d-41f9-8c38-9f5f62cc90dd/3920b46c-5fab-4b63-b47f-2fa5c6714c36', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}]}, 'beeefe06-78a0-4e14-a932-cc8d734d542d': {'policy': [], 'current_values': [{'name': 'sda', 'path': '/rhev/data-center/mnt/glusterSD/gluster0.grove.silverorange.com:_data__sdb/30fd0a2f-ab42-4a8a-8f0b-67242dc2d15d/images/310d8b3e-d578-418d-9802-dc0ebcea06d6/aa758c51-8478-4273-aeef-d4b374b8d6b4', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}, {'name': 'sdb', 'path': '/rhev/data-center/mnt/glusterSD/gluster0.grove.silverorange.com:_data__sdb/30fd0a2f-ab42-4a8a-8f0b-67242dc2d15d/images/4072fda1-ec82-45c9-b353-91fceb13bf08/891f5982-dead-48b4-8907-caa1e309fa82', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}]}, '7e5156de-649d-4904-9092-21a699242a37': {'policy': [], 'current_values': [{'name': 'vda', 'path': '/rhev/data-center/mnt/10.11.0.9:_vmstorage_nvme0n1/a99cd663-f6d5-42d8-bd7a-ee0b5d068608/images/ca0c1208-a7aa-4ef6-a450-4a40bd4455f3/a2335199-ddd4-429b-b55d-f4d527081fd3', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}]}}} from=::1,35012 (api:54) 2021-05-27 17:10:31,118+0000 WARN (migmon/7e5156de) [virt.vm] (vmId='7e5156de-649d-4904-9092-21a699242a37') Migration stalling: remaining (32863MiB) > lowmark (32863MiB). (migration:801) 2021-05-27 17:10:31,118+0000 INFO (migmon/7e5156de) [virt.vm] (vmId='7e5156de-649d-4904-9092-21a699242a37') Migration Progress: 190.035 seconds elapsed, 1% of data processed, total data: 32864MB, processed data: 0MB, remaining data: 32863MB, transfer speed 0Mbps, zero pages: 160MB, compressed: 0MB, dirty rate: 0, memory iteration: 1 (migration:814) 2021-05-27 17:10:33,827+0000 INFO (jsonrpc/5) [throttled] Current getAllVmStats: {'f8f4e4a1-b565-4663-8962-c8804dbb86fb': 'Up', '2b87204f-f695-474a-9f08-47b85fcac366': 'Up', '26332421-54a3-4afc-90e7-551a7e314c80': 'Up', '60edbd80-dad7-4bf8-8fd1-e138413cf9f6': 'Up', 'beeefe06-78a0-4e14-a932-cc8d734d542d': 'Up', '7e5156de-649d-4904-9092-21a699242a37': 'Migration Source'} (throttledlog:104) 2021-05-27 17:10:37,186+0000 INFO (jsonrpc/5) [api.host] FINISH getAllVmIoTunePolicies return={'status': {'code': 0, 'message': 'Done'}, 'io_tune_policies_dict': {'f8f4e4a1-b565-4663-8962-c8804dbb86fb': {'policy': [], 'current_values': [{'name': 'vda', 'path': '/rhev/data-center/mnt/10.11.0.9:_vmstorage_nvme1n1/bce04425-1d25-4489-bdab-2834a1a57db8/images/38b27cce-c744-4a12-85a3-3af07d386da2/93c1e793-f8cb-42c9-86a6-0e9ce4a6023a', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}]}, '2b87204f-f695-474a-9f08-47b85fcac366': {'policy': [], 'current_values': [{'name': 'sda', 'path': '/rhev/data-center/mnt/10.11.0.9:_vmstorage_nvme0n1/a99cd663-f6d5-42d8-bd7a-ee0b5d068608/images/f2e0c9f3-ab0d-441a-85a6-07a42e78b5a8/848f353e-6787-4e20-ab7b-0541ebd852c6', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}]}, '26332421-54a3-4afc-90e7-551a7e314c80': {'policy': [], 'current_values': [{'name': 'vda', 'path': '/rhev/data-center/mnt/10.11.0.9:_vmstorage_nvme0n1/a99cd663-f6d5-42d8-bd7a-ee0b5d068608/images/b7a785f9-307b-42af-9bbe-23cac884fe97/ed1d027e-a36a-4e6b-9207-119915044e06', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}]}, '60edbd80-dad7-4bf8-8fd1-e138413cf9f6': {'policy': [], 'current_values': [{'name': 'sda', 'path': '/rhev/data-center/mnt/10.11.0.9:_vmstorage_nvme2n1/a7efa448-201b-4453-9bc9-900559b891ca/images/535fcb2e-ece9-4d50-86fe-bf6264d11ae1/6c01a036-8a14-46ba-a4b4-fe4f66a586a3', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}, {'name': 'sdb', 'path': '/rhev/data-center/mnt/10.11.0.9:_vmstorage_nvme2n1/a7efa448-201b-4453-9bc9-900559b891ca/images/1f467fb5-5ea7-42ba-bace-f175c86791b2/cbe8327f-9b7f-442f-a650-6888bb11a674', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}, {'name': 'sdd', 'path': '/rhev/data-center/mnt/10.11.0.9:_vmstorage_nvme2n1/a7efa448-201b-4453-9bc9-900559b891ca/images/c93956d5-c88d-41f9-8c38-9f5f62cc90dd/3920b46c-5fab-4b63-b47f-2fa5c6714c36', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}]}, 'beeefe06-78a0-4e14-a932-cc8d734d542d': {'policy': [], 'current_values': [{'name': 'sda', 'path': '/rhev/data-center/mnt/glusterSD/gluster0.grove.silverorange.com:_data__sdb/30fd0a2f-ab42-4a8a-8f0b-67242dc2d15d/images/310d8b3e-d578-418d-9802-dc0ebcea06d6/aa758c51-8478-4273-aeef-d4b374b8d6b4', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}, {'name': 'sdb', 'path': '/rhev/data-center/mnt/glusterSD/gluster0.grove.silverorange.com:_data__sdb/30fd0a2f-ab42-4a8a-8f0b-67242dc2d15d/images/4072fda1-ec82-45c9-b353-91fceb13bf08/891f5982-dead-48b4-8907-caa1e309fa82', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}]}, '7e5156de-649d-4904-9092-21a699242a37': {'policy': [], 'current_values': [{'name': 'vda', 'path': '/rhev/data-center/mnt/10.11.0.9:_vmstorage_nvme0n1/a99cd663-f6d5-42d8-bd7a-ee0b5d068608/images/ca0c1208-a7aa-4ef6-a450-4a40bd4455f3/a2335199-ddd4-429b-b55d-f4d527081fd3', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}]}}} from=::1,35012 (api:54) 2021-05-27 17:10:41,120+0000 WARN (migmon/7e5156de) [virt.vm] (vmId='7e5156de-649d-4904-9092-21a699242a37') Migration stalling: remaining (32863MiB) > lowmark (32863MiB). (migration:801) 2021-05-27 17:10:41,120+0000 INFO (migmon/7e5156de) [virt.vm] (vmId='7e5156de-649d-4904-9092-21a699242a37') Migration Progress: 200.037 seconds elapsed, 1% of data processed, total data: 32864MB, processed data: 0MB, remaining data: 32863MB, transfer speed 0Mbps, zero pages: 160MB, compressed: 0MB, dirty rate: 0, memory iteration: 1 (migration:814) 2021-05-27 17:10:51,121+0000 WARN (migmon/7e5156de) [virt.vm] (vmId='7e5156de-649d-4904-9092-21a699242a37') Migration stalling: remaining (32863MiB) > lowmark (32863MiB). (migration:801) 2021-05-27 17:10:51,121+0000 INFO (migmon/7e5156de) [virt.vm] (vmId='7e5156de-649d-4904-9092-21a699242a37') Migration Progress: 210.039 seconds elapsed, 1% of data processed, total data: 32864MB, processed data: 0MB, remaining data: 32863MB, transfer speed 0Mbps, zero pages: 160MB, compressed: 0MB, dirty rate: 0, memory iteration: 1 (migration:814) 2021-05-27 17:10:52,211+0000 INFO (jsonrpc/1) [api.host] FINISH getAllVmIoTunePolicies return={'status': {'code': 0, 'message': 'Done'}, 'io_tune_policies_dict': {'f8f4e4a1-b565-4663-8962-c8804dbb86fb': {'policy': [], 'current_values': [{'name': 'vda', 'path': '/rhev/data-center/mnt/10.11.0.9:_vmstorage_nvme1n1/bce04425-1d25-4489-bdab-2834a1a57db8/images/38b27cce-c744-4a12-85a3-3af07d386da2/93c1e793-f8cb-42c9-86a6-0e9ce4a6023a', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}]}, '2b87204f-f695-474a-9f08-47b85fcac366': {'policy': [], 'current_values': [{'name': 'sda', 'path': '/rhev/data-center/mnt/10.11.0.9:_vmstorage_nvme0n1/a99cd663-f6d5-42d8-bd7a-ee0b5d068608/images/f2e0c9f3-ab0d-441a-85a6-07a42e78b5a8/848f353e-6787-4e20-ab7b-0541ebd852c6', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}]}, '26332421-54a3-4afc-90e7-551a7e314c80': {'policy': [], 'current_values': [{'name': 'vda', 'path': '/rhev/data-center/mnt/10.11.0.9:_vmstorage_nvme0n1/a99cd663-f6d5-42d8-bd7a-ee0b5d068608/images/b7a785f9-307b-42af-9bbe-23cac884fe97/ed1d027e-a36a-4e6b-9207-119915044e06', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}]}, '60edbd80-dad7-4bf8-8fd1-e138413cf9f6': {'policy': [], 'current_values': [{'name': 'sda', 'path': '/rhev/data-center/mnt/10.11.0.9:_vmstorage_nvme2n1/a7efa448-201b-4453-9bc9-900559b891ca/images/535fcb2e-ece9-4d50-86fe-bf6264d11ae1/6c01a036-8a14-46ba-a4b4-fe4f66a586a3', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}, {'name': 'sdb', 'path': '/rhev/data-center/mnt/10.11.0.9:_vmstorage_nvme2n1/a7efa448-201b-4453-9bc9-900559b891ca/images/1f467fb5-5ea7-42ba-bace-f175c86791b2/cbe8327f-9b7f-442f-a650-6888bb11a674', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}, {'name': 'sdd', 'path': '/rhev/data-center/mnt/10.11.0.9:_vmstorage_nvme2n1/a7efa448-201b-4453-9bc9-900559b891ca/images/c93956d5-c88d-41f9-8c38-9f5f62cc90dd/3920b46c-5fab-4b63-b47f-2fa5c6714c36', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}]}, 'beeefe06-78a0-4e14-a932-cc8d734d542d': {'policy': [], 'current_values': [{'name': 'sda', 'path': '/rhev/data-center/mnt/glusterSD/gluster0.grove.silverorange.com:_data__sdb/30fd0a2f-ab42-4a8a-8f0b-67242dc2d15d/images/310d8b3e-d578-418d-9802-dc0ebcea06d6/aa758c51-8478-4273-aeef-d4b374b8d6b4', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}, {'name': 'sdb', 'path': '/rhev/data-center/mnt/glusterSD/gluster0.grove.silverorange.com:_data__sdb/30fd0a2f-ab42-4a8a-8f0b-67242dc2d15d/images/4072fda1-ec82-45c9-b353-91fceb13bf08/891f5982-dead-48b4-8907-caa1e309fa82', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}]}, '7e5156de-649d-4904-9092-21a699242a37': {'policy': [], 'current_values': [{'name': 'vda', 'path': '/rhev/data-center/mnt/10.11.0.9:_vmstorage_nvme0n1/a99cd663-f6d5-42d8-bd7a-ee0b5d068608/images/ca0c1208-a7aa-4ef6-a450-4a40bd4455f3/a2335199-ddd4-429b-b55d-f4d527081fd3', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}]}}} from=::1,35012 (api:54) 2021-05-27 17:11:01,123+0000 WARN (migmon/7e5156de) [virt.vm] (vmId='7e5156de-649d-4904-9092-21a699242a37') Migration stalling: remaining (32863MiB) > lowmark (32863MiB). (migration:801) 2021-05-27 17:11:01,123+0000 INFO (migmon/7e5156de) [virt.vm] (vmId='7e5156de-649d-4904-9092-21a699242a37') Migration Progress: 220.041 seconds elapsed, 1% of data processed, total data: 32864MB, processed data: 0MB, remaining data: 32863MB, transfer speed 0Mbps, zero pages: 160MB, compressed: 0MB, dirty rate: 0, memory iteration: 1 (migration:814)ats return={'86245648-abd8-46e3-9c10-432e8788a074': {'code': 0, 'lastCheck': '1.6', 'delay': '0.00353497', 'valid': True, 'version': 5, 'acquired': True, 'actual': True}} from=::1,35010, task_id=c4e65f55-1367-41d3-9bf6-f357a382df4a (api:54) 2021-05-27 17:09:33,156+0000 INFO (jsonrpc/2) [api.host] START getStats() from=::ffff:10.11.0.219,54952 (api:48)

1 2

Ovirt 4.4.6.8-1 upload ova as template to multiple hosts
by Don Dupuis 27 May '21

27 May '21

I have a single ovirt manager and 2 ovirt hosts, each has a local storage domain. I am using the upload_ova_as_template.py and my template upload works on a single host but not both. If I use the gui method, there is the option of "clone" and putting in a new name for the template. This seems to work most of the time, but it has failed a couple of times also. I would like to add the same "clone" and "name" option to the upload_ova_as_temple.py. What is the best way to do this since I need to have unique UUIDs for the template disks? This is a unique setup in the fact that I can't use shared storage and this should be doable as I was able to do it in the ovirt gui. Thanks Don

2 7

what does dwh db contain?
by Nathanaël Blanchet 27 May '21

27 May '21

Hello, I need to understand which user removed a vm 2 months ago, but I can't recover such info into engine.log (that default rotate is 20). I gave a quick look to the dwh database: I'm able to find the removal date, but not the associated user. Is there a way to get this information? -- 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 0

Re: CPU Compatibility Problem after Upgrading Centos 8 Stream Host
by Jeff Bailey 27 May '21

27 May '21

If it's the same problem that I ran into then it's the latest version of edk2-ovmf. I'm not sure why it was pushed into the repos without a fixed libvirt to go with it. On 5/25/2021 7:20 AM, Nur Imam Febrianto wrote: > > Hi, > > This morning I have a problem that suddenly my Host (Using Centos 8 > Stream, not oVirt Node) showing error with Cpu Compatibility. It says > my CPU doesn’t have Haswell-noTSX and spec_ctrl flag. After > downgrading the kernel back from 4.18.0 – 305 to 4.18.0 – 301.1 and > rollback yum update, it working again. Do anybody having same issue ? > > I’m using Xeon E5-2695v4 with cluster compatibility Secure Intel > Haswell. Using oVirt 4.4.6 on CentOS Stream host. > > Thanks before. > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows 10 > > > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/privacy-policy.html > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/7R7SFBOPQL5S6…

4 7

Live ("any") disk migration between storages KILLS a virtual machine with Windows (UEFI) !!!
by Patrick Lomakin 27 May '21

27 May '21

The weekend went horribly. I created a second storage domain in order to move all the virtual machines to a higher performance RAID array (From RAID6 to RAID10). My mistake was trying to move two Windows domain controllers from one storage domain to another. The problem is that when I "live" moved the virtual machine disk between storage domains, my Windows Server 2019 virtual machines worked fine until the next reboot. After a reboot, the machine just won't start and throws an error - Status: 0xc0000428 - The digital signature for this file couldn't be verified. Moving back to the "old" domain doesn't help. None of the procedures with VMs worked (Re-create boot area, turn on kernel flag - bcdedit.exe /set nointegritychecks on). I am ready to help and interested in developing Ovirt. I can also provide more information to developers if needed.

3 5

Re: Parent checkpoint ID does not match the actual leaf checkpoint
by Nir Soffer 27 May '21

27 May '21

On Sun, Jul 19, 2020 at 5:38 PM Łukasz Kołaciński <l.kolacinski(a)storware.eu> wrote: > Hello, > Thanks to previous answers, I was able to make backups. Unfortunately, we > had some infrastructure issues and after the host reboots new problems > appeared. I am not able to do any backup using the commands that worked > yesterday. I looked through the logs and there is something like this: > > 2020-07-17 15:06:30,644+02 ERROR > [org.ovirt.engine.core.bll.StartVmBackupCommand] > (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-54) > [944a1447-4ea5-4a1c-b971-0bc612b6e45e] Failed to execute VM backup > operation 'StartVmBackup': {}: > org.ovirt.engine.core.common.errors.EngineException: EngineException: > org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: > VDSGenericException: VDSErrorException: Failed to StartVmBackupVDS, error = > Checkpoint Error: {'parent_checkpoint_id': None, 'leaf_checkpoint_id': > 'cd078706-84c0-4370-a6ec-654ccd6a21aa', 'vm_id': > '116aa6eb-31a1-43db-9b1e-ad6e32fb9260', 'reason': '*Parent checkpoint ID > does not match the actual leaf checkpoint*'}, code = 1610 (Failed with > error unexpected and code 16) > > It looks like engine sent: parent_checkpoint_id: None This issue was fix in engine few weeks ago. Which engine and vdsm versions are you testing? > at > deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.VdsHandler.handleVdsResult(VdsHandler.java:114) > at > deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.VDSBrokerFrontendImpl.runVdsCommand(VDSBrokerFrontendImpl.java:33) > at > deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.CommandBase.runVdsCommand(CommandBase.java:2114) > at > deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.StartVmBackupCommand.performVmBackupOperation(StartVmBackupCommand.java:368) > at > deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.StartVmBackupCommand.runVmBackup(StartVmBackupCommand.java:225) > at > deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.StartVmBackupCommand.performNextOperation(StartVmBackupCommand.java:199) > at > deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback.childCommandsExecutionEnded(SerialChildCommandsExecutionCallback.java:32) > at > deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.ChildCommandsCallbackBase.doPolling(ChildCommandsCallbackBase.java:80) > at > deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.tasks.CommandCallbacksPoller.invokeCallbackMethodsImpl(CommandCallbacksPoller.java:175) > at > deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.tasks.CommandCallbacksPoller.invokeCallbackMethods(CommandCallbacksPoller.java:109) > at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > at > org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.access$201(ManagedScheduledThreadPoolExecutor.java:383) > at > org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.run(ManagedScheduledThreadPoolExecutor.java:534) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > at > org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250) > > > And the last error is: > > 2020-07-17 15:13:45,835+02 ERROR > [org.ovirt.engine.core.bll.StartVmBackupCommand] > (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-14) > [f553c1f2-1c99-4118-9365-ba6b862da936] Failed to execute VM backup > operation 'GetVmBackupInfo': {}: > org.ovirt.engine.core.common.errors.EngineException: EngineException: > org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: > VDSGenericException: VDSErrorException: Failed to GetVmBackupInfoVDS, error > = No such backup Error: {'vm_id': '116aa6eb-31a1-43db-9b1e-ad6e32fb9260', > 'backup_id': 'bf1c26f7-c3e5-437c-bb5a-255b8c1b3b73', 'reason': '*VM > backup not exists: Domain backup job id not found: no domain backup job > present'*}, code = 1601 (Failed with error unexpected and code 16) > > This is likely a result of the first error. If starting backup failed the backup entity is deleted. > (these errors are from full backup) > > Like I said this is very strange because everything was working correctly. > > > Regards > > Łukasz Kołaciński > > Junior Java Developer > > e-mail: l.kolacinski(a)storware.eu > <m.helbert(a)storware.eu> > > > > > *[image: STORWARE]* <http://www.storware.eu/> > > > > *ul. Leszno 8/44 01-192 Warszawa www.storware.eu > <https://www.storware.eu/>* > > *[image: facebook]* <https://www.facebook.com/storware> > > *[image: twitter]* <https://twitter.com/storware> > > *[image: linkedin]* <https://www.linkedin.com/company/storware> > > *[image: Storware_Stopka_09]* > <https://www.youtube.com/channel/UCKvLitYPyAplBctXibFWrkw> > > > > *Storware Spółka z o.o. nr wpisu do ewidencji KRS dla M.St. Warszawa > 000510131* *, NIP 5213672602.** Wiadomość ta jest przeznaczona jedynie > dla osoby lub podmiotu, który jest jej adresatem i może zawierać poufne > i/lub uprzywilejowane informacje. Zakazane jest jakiekolwiek przeglądanie, > przesyłanie, rozpowszechnianie lub inne wykorzystanie tych informacji lub > podjęcie jakichkolwiek działań odnośnie tych informacji przez osoby lub > podmioty inne niż zamierzony adresat. Jeżeli Państwo otrzymali przez > pomyłkę tę informację prosimy o poinformowanie o tym nadawcy i usunięcie > tej wiadomości z wszelkich komputerów. **This message is intended only > for the person or entity to which it is addressed and may contain > confidential and/or privileged material. Any review, retransmission, > dissemination or other use of, or taking of any action in reliance upon, > this information by persons or entities other than the intended recipient > is prohibited. If you have received this message in error, please contact > the sender and remove the material from all of your computer systems.* > > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/privacy-policy.html > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/S3PLYPOZGT6TL… >

3 4

Re: CPU Compatibility Problem after Upgrading Centos 8 Stream Host
by k.gunasekhar＠non.keysight.com 27 May '21

27 May '21

I also end up with the same problem today. How did rollback yum i see many yum updates in the yum history. Here is what the error says. The host CPU does not match the Cluster CPU Type and is running in a degraded mode. It is missing the following CPU flags: model_IvyBridge, spec_ctrl. Please update the host CPU microcode or change the Cluster CPU Type.

2 1