- Users - oVirt List Archives

[ANN] oVirt 4.4.4 is now generally available
by Sandro Bonazzola 22 Jan '21

22 Jan '21

oVirt 4.4.4 is now generally available The oVirt project is excited to announce the general availability of oVirt 4.4.4 , as of December 21st, 2020. This release unleashes an altogether more powerful and flexible open source virtualization solution that encompasses hundreds of individual changes and a wide range of enhancements across the engine, storage, network, user interface, and analytics, as compared to oVirt 4.3. Important notes before you install / upgrade Please note that oVirt 4.4 only supports clusters and data centers with compatibility version 4.2 and above. If clusters or data centers are running with an older compatibility version, you need to upgrade them to at least 4.2 (4.3 is recommended). Please note that in RHEL 8 / CentOS 8 several devices that worked on EL7 are no longer supported. For example, the megaraid_sas driver is removed. If you use Enterprise Linux 8 hosts you can try to provide the necessary drivers for the deprecated hardware using the DUD method (See the users’ mailing list thread on this at https://lists.ovirt.org/archives/list/users@ovirt.org/thread/NDSVUZSESOXEFJ… ) 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>. What’s new in oVirt 4.4.4 Release? This update is the fourth in a series of stabilization updates to the 4.4 series. This release is available now on x86_64 architecture for: - Red Hat Enterprise Linux 8.3 - CentOS Linux (or similar) 8.3 - CentOS Stream (tech preview) This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: - Red Hat Enterprise Linux 8.3 - CentOS Linux (or similar) 8.3 - oVirt Node (based on CentOS Linux 8.3) - CentOS Stream (tech preview) oVirt Node and Appliance have been updated, including: - oVirt 4.4.4: https://www.ovirt.org/release/4.4.4/ - Ansible 2.9.16: https://github.com/ansible/ansible/blob/stable-2.9/changelogs/CHANGELOG-v2.… - CentOS Linux 8 (2011): https://lists.centos.org/pipermail/centos-announce/2020-December/048207.html - Advanced Virtualization 8.3 See the release notes [1] for installation instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available for CentOS Linux 8 - oVirt Node NG is already available for CentOS Linux 8 Additional resources: - Read more about the oVirt 4.4.4 release highlights: https://www.ovirt.org/release/4.4.4/ - Get more oVirt project updates on Twitter: https://twitter.com/ovirt - Check out the latest project news on the oVirt blog: https://blogs.ovirt.org/ [1] https://www.ovirt.org/release/4.4.4/ [2] https://resources.ovirt.org/pub/ovirt-4.4/iso/ -- 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.*

14 32

[ANN] oVirt 4.4.5 Second Release Candidate is now available for testing
by Sandro Bonazzola 22 Jan '21

22 Jan '21

oVirt 4.4.5 Second Release Candidate is now available for testing The oVirt Project is pleased to announce the availability of oVirt 4.4.5 Second Release Candidate for testing, as of January 21st, 2021. This update is the fifth 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.5 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.5 (redeploy in case of already being on 4.4.5). 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.3 or newer * CentOS Linux (or similar) 8.3 or newer This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: * Red Hat Enterprise Linux 8.3 or newer * CentOS Linux (or similar) 8.3 or newer * oVirt Node 4.4 based on CentOS Linux 8.3 (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 for CentOS Linux 8 - oVirt Node NG is already available for CentOS Linux 8 - We found a few issues while testing on CentOS Stream so we are still basing oVirt 4.4.5 Node and Appliance on CentOS Linux. Additional Resources: * Read more about the oVirt 4.4.5 release highlights: http://www.ovirt.org/release/4.4.5/ * 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.5/ [2] http://resources.ovirt.org/pub/ovirt-4.4-pre/iso/ -- 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.*

1 0

Cinderlib died after upgrade Cluster Compatibility version 4.4 ->4.5
by Mike Andreev 21 Jan '21

21 Jan '21

hi all, after upgrade oVirt 4.4.7 Cluster Compatibility version 4.4 ->4.5 cinderlib storage is died: tail -f /var/log/ovirt-engine/cinderlib/cinderlib.log 2021-01-20 12:35:28,781 - cinderlib-client - ERROR - Failure occurred when trying to run command 'delete_volume': Volume type with name __DEFAULT__ could not be found. [3d4a9aa9-c5f0-498c-b650-bc64d979f194] 2021-01-20 12:43:31,209 - cinderlib-client - ERROR - Failure occurred when trying to run command 'delete_volume': Volume type with name __DEFAULT__ could not be found. [927a1e82-aa21-4358-b213-120682d85e63] 2021-01-20 13:05:32,833 - cinderlib-client - ERROR - Failure occurred when trying to run command 'create_volume': Volume type with name __DEFAULT__ could not be found. [b645c321-5c64-4c54-972a-f81080bb6b0f] 2021-01-20 15:16:45,667 - cinderlib-client - ERROR - Failure occurred when trying to run command 'connect_volume': Volume type with name __DEFAULT__ could not be found. [19d98e01] 2021-01-20 15:16:48,232 - cinderlib-client - ERROR - Failure occurred when trying to run command 'connect_volume': Volume type with name __DEFAULT__ could not be found. [2088beea] 2021-01-20 15:16:50,320 - cinderlib-client - ERROR - Failure occurred when trying to run command 'disconnect_volume': Volume type with name __DEFAULT__ could not be found. [793923ab] 2021-01-20 15:37:28,423 - cinderlib-client - ERROR - Failure occurred when trying to run command 'connect_volume': Volume type with name __DEFAULT__ could not be found. [5c8f0d73] 2021-01-20 15:37:30,707 - cinderlib-client - ERROR - Failure occurred when trying to run command 'connect_volume': Volume type with name __DEFAULT__ could not be found. [35e96dcd] 2021-01-20 15:55:36,179 - cinderlib-client - ERROR - Failure occurred when trying to run command 'create_volume': Volume type with name __DEFAULT__ could not be found. [b5fbb358-36c7-4d3b-9431-16b3a699f300] 2021-01-20 15:57:33,733 - cinderlib-client - ERROR - Failure occurred when trying to run command 'create_volume': Volume type with name __DEFAULT__ could not be found. [ae879975-d36a-4b2b-9829-2713266f1c1f] in engine.log: 021-01-20 15:57:31,795+01 INFO [org.ovirt.engine.core.bll.storage.disk.AddDiskCommand] (default task-2) [ae879975-d36a-4b2b-9829-2713266f1c1f] Running command: AddDiskCommand internal: false. Entities affected : ID: 32dd7b42-eeb7-4cf5-9bef-bd8f8dd9608e Type: StorageAction group CREATE_DISK with role type USER 2021-01-20 15:57:32,014+01 INFO [org.ovirt.engine.core.bll.storage.disk.managedblock.AddManagedBlockStorageDiskCommand] (EE-ManagedExecutorService-commandCoordinator-Thread-1) [ae879975-d36a-4b2b-9829-2713266f1c1f] Running command: AddManagedBlockStorageDiskCommand internal: true. 2021-01-20 15:57:33,936+01 ERROR [org.ovirt.engine.core.common.utils.cinderlib.CinderlibExecutor] (EE-ManagedExecutorService-commandCoordinator-Thread-1) [ae879975-d36a-4b2b-9829-2713266f1c1f] cinderlib execution failed: 2021-01-20 15:57:34,012+01 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-2) [] EVENT_ID: USER_ADD_DISK_FINISHED_FAILURE(2,022), Add-Disk operation failed to complete. 2021-01-20 15:57:34,090+01 INFO [org.ovirt.engine.core.bll.storage.disk.AddDiskCommandCallback] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-47) [ae879975-d36a-4b2b-9829-2713266f1c1f] Command 'AddDisk' id: 'c7e43317-495e-4b97-96cd-02f02cb20ab2' child commands '[1de7bfa3-09c3-45a5-955a-580236f0296c]' executions were completed, status 'FAILED' 2021-01-20 15:57:35,127+01 ERROR [org.ovirt.engine.core.bll.storage.disk.AddDiskCommand] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-48) [ae879975-d36a-4b2b-9829-2713266f1c1f] Ending command 'org.ovirt.engine.core.bll.storage.disk.AddDiskCommand' with failure. 2021-01-20 15:57:35,135+01 ERROR [org.ovirt.engine.core.bll.storage.disk.managedblock.AddManagedBlockStorageDiskCommand] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-48) [ae879975-d36a-4b2b-9829-2713266f1c1f] Ending command 'org.ovirt.engine.core.bll.storage.disk.managedblock.AddManagedBlockStorageDiskCommand' with failure. I check it on cinderlib 2.0, 2.1, 3.0 installed as from rpm (ussuri) and from pip install - errors the same. on backend we use CEPH 14 rbd pools

2 5

Gluster Hyperconverged fails with single disk partitioned
by Shantur Rathore 21 Jan '21

21 Jan '21

Hi, I am trying to setup a single host Self-Hosted hyperconverged setup with GlusterFS. I have a custom partitioning where I provide 100G for oVirt and its partitions and rest 800G to a physical partition (/dev/sda4). When I try to create gluster deployment with the wizard, it fails TASK [gluster.infra/roles/backend_setup : Create volume groups] **************** failed: [ovirt-macpro-16.lab.ced.bskyb.com] (item={'key': 'gluster_vg_sda4', 'value': [{'vgname': 'gluster_vg_sda4', 'pvname': '/dev/sda4'}]}) => {"ansible_loop_var": "item", "changed": false, "err": " Device /dev/sda4 excluded by a filter.\n", "item": {"key": "gluster_vg_sda4", "value": [{"pvname": "/dev/sda4", "vgname": "gluster_vg_sda4"}]}, "msg": "Creating physical volume '/dev/sda4' failed", "rc": 5} I checked and /etc/lvm/lvm.conf filter doesn't allow /dev/sda4. It only allows PV for onn VG. Once I manually allow /dev/sda4 to lvm filter, it works fine and gluster deployment completes. Fdisk : # fdisk -l /dev/sda Disk /dev/sda: 931.9 GiB, 1000555581440 bytes, 1954210120 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: FE209000-85B5-489A-8A86-4CF0C91B2E7D Device Start End Sectors Size Type /dev/sda1 2048 1230847 1228800 600M EFI System /dev/sda2 1230848 3327999 2097152 1G Linux filesystem /dev/sda3 3328000 213043199 209715200 100G Linux LVM /dev/sda4 213043200 1954209791 1741166592 830.3G Linux filesystem LVS # lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert home onn Vwi-aotz-- 10.00g pool0 0.11 ovirt-node-ng-4.4.4-0.20201221.0 onn Vwi---tz-k 10.00g pool0 root ovirt-node-ng-4.4.4-0.20201221.0+1 onn Vwi-aotz-- 10.00g pool0 ovirt-node-ng-4.4.4-0.20201221.0 25.26 pool0 onn twi-aotz-- 95.89g 2.95 14.39 root onn Vri---tz-k 10.00g pool0 swap onn -wi-ao---- 4.00g tmp onn Vwi-aotz-- 10.00g pool0 0.12 var onn Vwi-aotz-- 20.00g pool0 0.92 var_crash onn Vwi-aotz-- 10.00g pool0 0.11 var_log onn Vwi-aotz-- 10.00g pool0 0.13 var_log_audit onn Vwi-aotz-- 4.00g pool0 0.27 # grep filter /etc/lvm/lvm.conf filter = ["a|^/dev/disk/by-id/lvm-pv-uuid-QrvErF-eaS9-PxbI-wCBV-3OxJ-V600-NG7raZ$|", "r|.*|"] Am I doing something which oVirt isn't expecting? Is there anyway to provide tell gluster deployment to add it to lvm config. Thanks, Shantur

2 3

Change of IP's
by Román Larumbe S. 21 Jan '21

21 Jan '21

Hello, I have a Dell VRTX with 2 M640 servers, we installed oVirt version 4.3.10.4-1.el7, we have 1 cluster, 2 hosts and 2 storage domains. I need to change ALL the network environment solution, that is, from IP's 192.168.11.XX to 172.16.10.XX. Can anybody help me? Thank you. Román Larumbe S. Facebook: Serahp LS

2 1

VMware Fence Agent
by Robert Tongue 21 Jan '21

21 Jan '21

Greetings all, I am new to oVirt, and have a proof of concept setup with a 3-node oVirt cluster nested inside of VMware VCenter to learn it, so then I can efficiently migrate that back out to the physical nodes to replace VCenter. I have gotten all the way to a working cluster setup, with the exception of fencing. I used engine-config to pull in the vmware_soap fence agent, and enabled all the options, however there is one small thing I cannot figure out. The connection uses a self-signed certificate on the vcenter side, and I cannot figure out the proper combination of engine-config -s commands to get the script to be called with the "ssl-insecure" option, which does contain a value. It just needs the option passed. Is there anyone out there in the ether that can help me out? I can provide any information you request. Thanks in advance. The fence agent script is called with the following syntax in my tests, and returned the proper status: [root@cluster2-vm ~]# /usr/sbin/fence_vmware_soap -o status -a vcenter.address --username="administrator(a)vsphere.local" --password="0bfusc@t3d" --ssl-insecure -n cluster1-vm Status: ON -phunyguy

1 0

Why cannot create new volume ?
by tommy 21 Jan '21

21 Jan '21

3 7

Mutually exclusive VMs
by Shantur Rathore 21 Jan '21

21 Jan '21

Hi all, I am trying to figure if there is a way to force oVirt to schedule VMs on different hosts. So if I am cloning 6 VMs from a template, I want oVirt to schedule them on all different hosts. No 2 VMs must schedule on the same host. I know that there is pin-to-host functionality but I don't want to manually pin it to hosts. Thanks Shantur

2 1

Unable to edit DNS connfiguration on hosts
by miguel.garcia＠toshibagcs.com 20 Jan '21

20 Jan '21

I had to replace the DNS server in my network so I want to update the DNS address on each host so in oVirt web interface I go to Compute > Host > Hostname > Network Interfaces > Setup Host Networks Right there I click on the edit button of the vlan for networking, check out (host ip address is static), DNS configuration, check DNS configuration, Type DNS ip address and click ok to save change. I got message: Error while executing action HostSetupNetworks: Unexpected Exception. Into engile.log found message "Operation not permitted" related to this action despite that was executed with my user account (wint admin privileges) and same message was returned using admin@internal user. 2021-01-20 11:35:31,579-05 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand] (default task-482931) [b9a19834-3f15-42da-af2c-55e292dfedea] START, HostSetupNetworksVDSCommand(HostName = hyp10.eboss, HostSetupNetworksVdsCommandParameters:{hostId='39c05625-7b59-4a38-a5a9-5d556ae1fe18', vds='Host[hyp10.eboss,39c05625-7b59-4a38-a5a9-5d556ae1fe18]', rollbackOnFailure='true', commitOnSuccess='true', connectivityTimeout='120', networks='[HostNetwork:{defaultRoute='true', bonding='false', networkName='tgcs182vlan', vdsmName='tgcs182vlan', nicName='eno1', vlan='null', vmNetwork='true', stp='false', properties='[]', ipv4BootProtocol='STATIC_IP', ipv4Address='10.89.182.10', ipv4Netmask='255.255.255.0', ipv4Gateway='10.89.182.1', ipv6BootProtocol='AUTOCONF', ipv6Address='null', ipv6Prefix='null', ipv6Gateway='null', nameServers='[NameServer:{address='10.89.182.204'}, NameServer:{address='10.89.176.71'}]'}]', removedNetworks='[]', bonds='[]', removedBonds='[]', clusterSw itchType='OVS', managementNetworkChanged='false'}), log id: 23059843 2021-01-20 11:35:31,582-05 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand] (default task-482931) [b9a19834-3f15-42da-af2c-55e292dfedea] FINISH, HostSetupNetworksVDSCommand, return: , log id: 23059843 2021-01-20 11:35:35,665-05 WARN [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand] (default task-482931) [b9a19834-3f15-42da-af2c-55e292dfedea] Unexpected return value: Status [code=-32603, message=Internal JSON-RPC error: {'reason': '[Errno 1] Operation not permitted'}] 2021-01-20 11:35:35,665-05 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand] (default task-482931) [b9a19834-3f15-42da-af2c-55e292dfedea] Failed in 'HostSetupNetworksVDS' method 2021-01-20 11:35:35,666-05 WARN [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand] (default task-482931) [b9a19834-3f15-42da-af2c-55e292dfedea] Unexpected return value: Status [code=-32603, message=Internal JSON-RPC error: {'reason': '[Errno 1] Operation not permitted'}] 2021-01-20 11:35:35,673-05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-482931) [b9a19834-3f15-42da-af2c-55e292dfedea] EVENT_ID: VDS_BROKER_COMMAND_FAILURE(10,802), VDSM hyp10.eboss command HostSetupNetworksVDS failed: Internal JSON-RPC error: {'reason': '[Errno 1] Operation not permitted'} 2021-01-20 11:35:35,673-05 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand] (default task-482931) [b9a19834-3f15-42da-af2c-55e292dfedea] Error: VDSGenericException: VDSErrorException: Failed to HostSetupNetworksVDS, error = Internal JSON-RPC error: {'reason': '[Errno 1] Operation not permitted'}, code = -32603 2021-01-20 11:35:35,673-05 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand] (default task-482931) [b9a19834-3f15-42da-af2c-55e292dfedea] Command 'HostSetupNetworksVDSCommand(HostName = hyp10.eboss, HostSetupNetworksVdsCommandParameters:{hostId='39c05625-7b59-4a38-a5a9-5d556ae1fe18', vds='Host[hyp10.eboss,39c05625-7b59-4a38-a5a9-5d556ae1fe18]', rollbackOnFailure='true', commitOnSuccess='true', connectivityTimeout='120', networks='[HostNetwork:{defaultRoute='true', bonding='false', networkName='tgcs182vlan', vdsmName='tgcs182vlan', nicName='eno1', vlan='null', vmNetwork='true', stp='false', properties='[]', ipv4BootProtocol='STATIC_IP', ipv4Address='10.89.182.10', ipv4Netmask='255.255.255.0', ipv4Gateway='10.89.182.1', ipv6BootProtocol='AUTOCONF', ipv6Address='null', ipv6Prefix='null', ipv6Gateway='null', nameServers='[NameServer:{address='10.89.182.204'}, NameServer:{address='10.89.176.71'}]'}]', removedNetworks='[]', bonds='[]', removedBonds='[]', cluster SwitchType='OVS', managementNetworkChanged='false'})' execution failed: VDSGenericException: VDSErrorException: Failed to HostSetupNetworksVDS, error = Internal JSON-RPC error: {'reason': '[Errno 1] Operation not permitted'}, code = -32603 2021-01-20 11:35:35,673-05 INFO [org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand] (default task-482931) [b9a19834-3f15-42da-af2c-55e292dfedea] Host setup networks finished. Lock released. Monitoring can run now for host 'hyp10.eboss' from data-center 'tgcs-gdl-dc1-public' 2021-01-20 11:35:35,673-05 ERROR [org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand] (default task-482931) [b9a19834-3f15-42da-af2c-55e292dfedea] Command 'org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand' failed: EngineException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to HostSetupNetworksVDS, error = Internal JSON-RPC error: {'reason': '[Errno 1] Operation not permitted'}, code = -32603 (Failed with error unexpected and code 16) 2021-01-20 11:35:35,677-05 INFO [org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand] (default task-482931) [b9a19834-3f15-42da-af2c-55e292dfedea] Lock freed to object 'EngineLock:{exclusiveLocks='[HOST_NETWORK39c05625-7b59-4a38-a5a9-5d556ae1fe18=HOST_NETWORK]', sharedLocks=''}' This error message happens even in master as in nodes hosts. Any idea how can I solve it? Thanks in advance

1 0

About Enroll Certificate
by tommy 20 Jan '21

20 Jan '21

Hi, What function of the Enroll Certificate ??

2 2