- Users - oVirt List Archives

where is error log for OVA import
by Philip Brown 01 Aug '20

01 Aug '20

I just tried to import an OVA file. The GUI status mentions that things seem to go along fairly happily.. it mentions that it creates a disk for it.... but then eventually just says "failed to import VM xxxxx into datacenter Default" with zero explanation. Isnt there a log file or something I can check, somewhere, to find out what the problem is? -- Philip Brown| Sr. Linux System Administrator | Medata, Inc. 5 Peters Canyon Rd Suite 250 Irvine CA 92606 Office 714.918.1310| Fax 714.918.1325 pbrown(a)medata.com| www.medata.com

4 6

testing ovirt 4.4 as single node VM inside 4.3
by Philip Brown 01 Aug '20

01 Aug '20

I'm having problems importing OVA exports from vmware 4, into ovirt 4.3 I've read that basically, this is a known issue and that ovirt 4.4 improves the import situation greatly. But I'd like to be able to prove it helps us, before comitting to large undertakings. Is it going to be doable to run a single node ovirt cluster as a VM inside another one? Or do I need to run it on bare metal? -- Philip Brown| Sr. Linux System Administrator | Medata, Inc. 5 Peters Canyon Rd Suite 250 Irvine CA 92606 Office 714.918.1310| Fax 714.918.1325 pbrown(a)medata.com| www.medata.com

4 4

Re: Changing FQDN
by Alex K 31 Jul '20

31 Jul '20

On Fri, Jul 31, 2020, 21:00 Alex K <rightkicktech(a)gmail.com> wrote: > > > On Fri, Jul 31, 2020, 18:26 Dominik Holler <dholler(a)redhat.com> wrote: > >> >> >> On Fri, Jul 31, 2020 at 4:00 PM Alex K <rightkicktech(a)gmail.com> wrote: >> >>> >>> >>> On Fri, Jul 31, 2020 at 4:50 PM Dominik Holler <dholler(a)redhat.com> >>> wrote: >>> >>>> >>>> >>>> On Fri, Jul 31, 2020 at 2:44 PM Alex K <rightkicktech(a)gmail.com> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I am running ovirt 4.2.8 >>>>> I did change ovirt engine FQDN using ovirt-engine-rename tool following >>>>> >>>>> >>>>> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/ht… >>>>> >>>>> Hosts FQDN is also changed and all seem fine apart from OVN connection >>>>> and ImageIO proxy. >>>>> >>>>> About OVN, i just configured OVN and when I test connection I get: >>>>> >>>>> Failed with error Certificate for <new fqdn> doesn't match any of the >>>>> subject alternative names: [old fqdn] and code 5050) >>>>> >>>> >>>> >>>> Can you please replace all occurrences of the old fqdn by the new fqdn >>>> in >>>> /etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf >>>> and >>>> systemctl restart ovirt-provider-ovn >>>> and let us know if this solves the problem? >>>> >>> DId it and the same error is reported. >>> Then tried to engine-setup and still same issue. >>> >> >> Can you please check if adjusting both URLs of the ovirt-provider-ovn >> external network provider in oVirt Engine in the >> oVirt Administration Portal -> Administration -> Providers -> >> ovirt-provider-ovn -> Edit >> solves the issue? >> > Forgot to mention that I had already changed that to reflect new fqdn. > Both url and hostname. > I think that the issue lies at the ca subject still referring to previous fqdn. > >> >> >>> >>>> This step is not yet automated by ovirt-engine-rename in oVirt-4.2. , >>>> please find more details in >>>> https://bugzilla.redhat.com/1501798 >>>> <https://bugzilla.redhat.com/show_bug.cgi?id=1501798> >>>> >>>> >>>> >>>> >>>>> >>>>> about Imageio proxy when I test the connection I do get nothing. No >>>>> error at engine.log or at GUI. >>>>> >>>>> Thus it seems that I have to generate/replace new certs. >>>>> Is there a way I can fix this until I switch to 4.3 and eventually to >>>>> 4.4 where it seems that this is handled from the rename tool? >>>>> >>>>> Thanks for any assistance. >>>>> Alex. >>>>> >>>>> _______________________________________________ >>>>> 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/XKOUI5FPDDUY3… >>>>> >>>>

1 0

4.4.x - VLAN-based logical network can't attach to bonds?
by Mark R 31 Jul '20

31 Jul '20

Hello all, New 4.4.1 hosted-engine install. Pre-deploy, the host already had bond0 and its iSCSI interfaces configured. The deploy correctly sets up the ovirtmgmt interface using the bond, and when everything finishes up it's working as expected. However, I then need to create a VLAN-based network and attach to the same bond0 interface. Editing the host networks and dragging the VLAN 102 interface to the bond alongside ovirtmgmt, then clicking "OK" results in a failure every time. The error returned is: VDSM ovirt5.domain.com command HostSetupNetworksVDS failed: Internal JSON-RPC error: {'reason': 'Unexpected failure of libnm when running the mainloop: run execution'} I can break the bond and apply this an any other VLAN-based network at will, but then it's not possible to add the interface I removed to create the bond again. That may be by design and it's not supposed to be possible to attach an interface and create a bond once you've already assigned logical networks to it. The error there is "Error while executing action HostSetupNetworks: Interface already in use". I'm just putting out feelers to see if this is a known issue that other people are hitting, or are other folks with hosted-engine 4.4.x deploys readily creating that initial bond0 interface and assigning any VLAN-based logical networks they want w/o issue? These same hosts (they still aren't in prod so I rebuild them at will) run 4.3 with no issues and setting up the exact same network configurations works flawlessly, it just becomes an issue on 4.4.1. This host was freshly installed today and has all updates. Thanks, Mark

3 7

Changing FQDN
by Alex K 31 Jul '20

31 Jul '20

Hi all, I am running ovirt 4.2.8 I did change ovirt engine FQDN using ovirt-engine-rename tool following https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/ht… Hosts FQDN is also changed and all seem fine apart from OVN connection and ImageIO proxy. About OVN, i just configured OVN and when I test connection I get: Failed with error Certificate for <new fqdn> doesn't match any of the subject alternative names: [old fqdn] and code 5050) about Imageio proxy when I test the connection I do get nothing. No error at engine.log or at GUI. Thus it seems that I have to generate/replace new certs. Is there a way I can fix this until I switch to 4.3 and eventually to 4.4 where it seems that this is handled from the rename tool? Thanks for any assistance. Alex.

2 1

Guest VM snapshots are not retained when importing data storage domain
by Alex K 31 Jul '20

31 Jul '20

Hi all, I have a dual node self hosted cluster v4.3 using gluster as storage so as to test an actual scenario which will need to be followed at production. The purpose is to rename the cluster FQDN to a new one, wiping out any reference to the old previous FQDN. I was not successful in using the engine-rename tool or other means as there are leftovers from previous FQDN that cause issues. The cluster has a data storage domain with one guest VM running on it which has one snapshot. I am testing a destructive scenario as below and I find out that when importing the storage domain to the newly configured cluster, while the guest VM is imported fine, I do not see the guest VM disk snapshots. Steps that I follow for this scenario: *Initial status: * I have an ovirt cluster with two hosts named v0 and v1. The gluster storage domain is configured at a separate network where the hosts are named gluster0 and gluster1. The cluster has an engine and data storage domain named "engine" and "vms" respectively. The "vms" storage domain hosts one guest VM with one guest VM disk snapshot. All are configured with fqdn *localdomain.local* *# Steps to rename all cluster to new fqdn lab.local and import "vms" storage domain* 1. Set v1 ovirt host at maintenance then remove it from GUI. 2. At v1 install fresh CentOS7 using the new FQDN lab.local 3. at v0 set global maintenance and shutdown engine. Remove the engine storage data. (complete wipe of any engine related data. What is important is only VM guests and their snapshots). 4. at v0, remove bricks belonging to "engine" and "vms" gluster volumes of v1 and detach gluster peer v1. gluster volume remove-brick engine replica 1 gluster1:/gluster/engine/brick force gluster volume remove-brick vms replica 1 gluster1:/gluster/vms/brick force gluster peer detach gluster1 5. On v1, prepare gluster service, reattach peer and add bricks from v0. At this phase all data from vms gluster volume will be synced to the new host. Verify with `gluster heal info vms`. from v0 server run: gluster peer probe gluster1 gluster volume add-brick engine replica 2 gluster1:/gluster/engine/brick gluster volume add-brick vms replica 2 gluster1:/gluster/vms/brick At this state all gluster volume are up and in sync. We confirm "vms" sync with gluster volume heal info vms 6. At freshly installed v1 install engine using the same clean gluster engine volume: hosted-engine --deploy --config-append=/root/storage.conf --config-append=answers.conf (use new FQDN!) 7. Upon completion of engine deployment and after having ensured the vms gluster volume is synced (step 5) remove bricks of v0 host (v0 now should not be visible at ovirt GUI) and detach gluster peer v0. at v1 host run: gluster volume remove-brick engine replica 1 gluster0:/gluster/engine/brick force gluster volume remove-brick vms replica 1 gluster0:/gluster/vms/brick force gluster peer detach gluster0 8. Install fresh CentOS7 on v0 and prepare it with ovirt node packages, networking and gluster. 9. At v0, attach gluster bricks from v1. Confirm sync with gluster volume heal info. at v1 host: gluster peer probe gluster0 gluster volume add-brick engine replica 2 gluster0:/gluster/engine/brick gluster volume add-brick vms replica 2 gluster0:/gluster/vms/brick 10. at engine, add entry for v0 host at /etc/hosts. At ovirt GUI, add v0. /etc/hosts: 10.10.10.220 node0 v0.lab.local 10.10.10.221 node1 v1.lab.local 10.10.10.222 engine.lab.local engine 10.100.100.1 gluster0 10.100.100.2 gluster1 11. At ovirt GUI import vms gluster volume as vms storage domain. At this step I have to approve operation: [image: image.png] 12. At ovirt GUI, import VMs from vms storage domain. At this step the VM is found and imported from the imported storage domain "vms", but the VM does not show the previously available disk snapshot. The import of the storage domain should have retained the guest VM snapshot. How can this be troubleshooted? Do I have to keep some type of engine DB backup so as to make the snapshots visible? If yes, is it possible to restore this backup to a fresh engine that has a new FQDN? Thanx very much for any advise and hint. Alex

2 3

best way to have storage vlan available to host AND vms?
by Philip Brown 30 Jul '20

30 Jul '20

I'm trying to allow a particular iSCSI VLAN to be available to all hosts.. but also to a few select VMs. Im finding this challenging, since prior to now, I did host iSCSI config on the host-local level. i used the cockpit GUI to create a "VLAN" entity, assigned it to an interface, and then configured an IP address. But when I attempt to create a "network"(/aka VLAN) entity from the main hosted-engine level.. it seems to conflict with prior host-local created ones. and when I remove the host-local entries... I no longer seem to have a way in the GUI to create IP addresses for the host, from host cockpit? It recognises that the entity exists, but put it in the "unmanaged" section. So.. how can I handle this best? -- Philip Brown| Sr. Linux System Administrator | Medata, Inc. 5 Peters Canyon Rd Suite 250 Irvine CA 92606 Office 714.918.1310| Fax 714.918.1325 pbrown(a)medata.com| www.medata.com

2 4

10GB disk created on glusterfs storage has only 4096B in vm
by Jiří Sléžka 30 Jul '20

30 Jul '20

Hi, I have another spooky issue. CentOS 8.2, oVirt 4.4.1.10-1 I am trying to create vm on my HCI cluster (which in fact has only two nodes now, the third will be added later). I have created new 10GB disk on gluster storage (it behaves the same way when I chose prealocated or thin provision disk). Everything looks good (I was surprised how fast was this disk created) but when I run the vm then disk has only 4096 bytes. see http://mirror.slu.cz/tmp/ovirt_small_disk.png disk creation part of engine.log is here https://paste.slu.cz/?0e33e800609898d8#CEC2maoe7zk9b1zmnHaAENjaAnpiyzzGzPFS… the same part in vdsm.log on SPM host https://paste.slu.cz/?e89fdce800c39b28#3UWw7dXxQAmZysMSKp5NbeTWMNDghZVh2NLE… where could be problem? Did anybody experience this behavior? Cheers, Jiri

4 7

PKI Problem
by ramon＠clematide.ch 30 Jul '20

30 Jul '20

Hi I did a fresh installation of version 4.4.0.3. After the engine setup I replaced the apache certificate with a custom certificate. I used this article to do it: https://myhomelab.gr/linux/2020/01/20/replacing_ovirt_ssl.html To summarize, I replaced those files with my own authority and the signed custom certificate /etc/pki/ovirt-engine/keys/apache.key.nopass /etc/pki/ovirt-engine/certs/apache.cer /etc/pki/ovirt-engine/apache-ca.pem That worked so far, apache uses now my certificate, login is possible. To setup a new machine, I need to upload an iso image, which failed. I found this error in /var/log/ovirt-imageio/daemon.log 2020-07-08 20:43:23,750 INFO (Thread-10) [http] OPEN client=192.168.1.228 2020-07-08 20:43:23,767 INFO (Thread-10) [backends.http] Open backend netloc='the_secret_hostname:54322' path='/images/ef60404c-dc69-4a3d-bfaa-8571f675f3e1' cafile='/etc/pki/ovirt-engine/apache-ca.pem' secure=True 2020-07-08 20:43:23,770 ERROR (Thread-10) [http] Server error Traceback (most recent call last): File "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/http.py", line 699, in __call__ self.dispatch(req, resp) File "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/http.py", line 744, in dispatch return method(req, resp, *match.groups()) File "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/cors.py", line 84, in wrapper return func(self, req, resp, *args) File "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/images.py", line 66, in put backends.get(req, ticket, self.config), File "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/backends/__init__.py", line 53, in get cafile=config.tls.ca_file) File "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/backends/http.py", line 48, in open secure=options.get("secure", True)) File "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/backends/http.py", line 63, in __init__ options = self._options() File "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/backends/http.py", line 364, in _options self._con.request("OPTIONS", self.url.path) File "/usr/lib64/python3.6/http/client.py", line 1254, in request self._send_request(method, url, body, headers, encode_chunked) File "/usr/lib64/python3.6/http/client.py", line 1300, in _send_request self.endheaders(body, encode_chunked=encode_chunked) File "/usr/lib64/python3.6/http/client.py", line 1249, in endheaders self._send_output(message_body, encode_chunked=encode_chunked) File "/usr/lib64/python3.6/http/client.py", line 1036, in _send_output self.send(msg) File "/usr/lib64/python3.6/http/client.py", line 974, in send self.connect() File "/usr/lib64/python3.6/http/client.py", line 1422, in connect server_hostname=server_hostname) File "/usr/lib64/python3.6/ssl.py", line 365, in wrap_socket _context=self, _session=session) File "/usr/lib64/python3.6/ssl.py", line 776, in __init__ self.do_handshake() File "/usr/lib64/python3.6/ssl.py", line 1036, in do_handshake self._sslobj.do_handshake() File "/usr/lib64/python3.6/ssl.py", line 648, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897) 2020-07-08 20:43:23,770 INFO (Thread-10) [http] CLOSE client=192.168.1.228 [connection 1 ops, 0.019775 s] [dispatch 1 ops, 0.003114 s] I'm a python developer so I had no problem reading the traceback. The SSL handshake fails when image-io tries to connect to what I think is called an ovn-provider. But it is using my new authority certificate cafile='/etc/pki/ovirt-engine/apache-ca.pem' which does not validate the certificate generated by the ovirt engine setup, which the ovn-provider probably uses. I didn't exactly know where the parameter for the validation ca file is. Probably it is the ca_file parameter in /etc/ovirt-imageio/conf.d/50-engine.conf. But that needs to be set to my own authority ca file. I modified the python file to set the ca_file parameter to the engine setups ca_file directly /usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/backends/__init__.py So the function call around line 50 looks like this: backend = module.open( ticket.url, mode, sparse=ticket.sparse, dirty=ticket.dirty, cafile='/etc/pki/ovirt-engine/ca.pem' #config.tls.ca_file ) Now the image upload works, but obviously this is not the way to fix things. Is there an other way to make image-io accept the certificate from the engine setup, while using my custom certificate? I don't want to replace the certificates of all ovirt components with custom certificates. I only need the weblogin with my custom certificate. Regards

4 9

Problem with paused VMs in ovirt 4.3.10.
by Dmitry Sekretev 30 Jul '20

30 Jul '20

Hi! We have a problem with paused VMs in ovirt cluster. Please, help to solve this. In ovirt manager massege "VM rtb-stagedsw02-ovh has been paused." Resume fails with error "Failed to resume VM rtb-stagedsw02-ovh (Host: ovirt-node09-ovh.local, User: admin@internal-authz)." In oVirt Cluster 38 VM, paused VM only ubuntu 20.04 focal with docker swarm. Archived logs in attach. Packeges on ovirt nodes: python2-ovirt-setup-lib-1.2.0-1.el7.noarch ovirt-vmconsole-1.0.7-2.el7.noarch ovirt-provider-ovn-driver-1.2.29-1.el7.noarch ovirt-vmconsole-host-1.0.7-2.el7.noarch python2-ovirt-host-deploy-1.8.5-1.el7.noarch ovirt-imageio-common-1.5.3-0.el7.x86_64 cockpit-machines-ovirt-195.6-1.el7.centos.noarch ovirt-ansible-engine-setup-1.1.9-1.el7.noarch ovirt-host-dependencies-4.3.5-1.el7.x86_64 ovirt-host-4.3.5-1.el7.x86_64 python-ovirt-engine-sdk4-4.3.4-2.el7.x86_64 ovirt-host-deploy-common-1.8.5-1.el7.noarch ovirt-ansible-hosted-engine-setup-1.0.32-1.el7.noarch ovirt-hosted-engine-setup-2.3.13-1.el7.noarch ovirt-ansible-repositories-1.1.5-1.el7.noarch ovirt-imageio-daemon-1.5.3-0.el7.noarch cockpit-ovirt-dashboard-0.13.10-1.el7.noarch ovirt-release43-4.3.10-1.el7.noarch ovirt-hosted-engine-ha-2.3.6-1.el7.noarch Packeges on HostedEngine: ovirt-ansible-infra-1.1.13-1.el7.noarch ovirt-vmconsole-1.0.7-2.el7.noarch ovirt-engine-setup-plugin-websocket-proxy-4.3.10.4-1.el7.noarch ovirt-engine-websocket-proxy-4.3.10.4-1.el7.noarch ovirt-engine-restapi-4.3.10.4-1.el7.noarch ovirt-ansible-engine-setup-1.1.9-1.el7.noarch ovirt-ansible-shutdown-env-1.0.3-1.el7.noarch ovirt-iso-uploader-4.3.2-1.el7.noarch ovirt-provider-ovn-1.2.29-1.el7.noarch ovirt-imageio-proxy-setup-1.5.3-0.el7.noarch ovirt-engine-extension-aaa-ldap-setup-1.3.10-1.el7.noarch ovirt-engine-setup-plugin-vmconsole-proxy-helper-4.3.10.4-1.el7.noarch python-ovirt-engine-sdk4-4.3.4-2.el7.x86_64 python2-ovirt-host-deploy-1.8.5-1.el7.noarch ovirt-ansible-vm-infra-1.1.22-1.el7.noarch ovirt-engine-metrics-1.3.7-1.el7.noarch ovirt-ansible-disaster-recovery-1.2.0-1.el7.noarch ovirt-engine-wildfly-overlay-17.0.1-1.el7.noarch ovirt-ansible-roles-1.1.7-1.el7.noarch ovirt-engine-dwh-setup-4.3.8-1.el7.noarch python2-ovirt-engine-lib-4.3.10.4-1.el7.noarch ovirt-engine-extension-aaa-ldap-1.3.10-1.el7.noarch ovirt-engine-setup-plugin-ovirt-engine-4.3.10.4-1.el7.noarch ovirt-engine-vmconsole-proxy-helper-4.3.10.4-1.el7.noarch ovirt-engine-tools-backup-4.3.10.4-1.el7.noarch ovirt-engine-webadmin-portal-4.3.10.4-1.el7.noarch ovirt-host-deploy-common-1.8.5-1.el7.noarch ovirt-ansible-image-template-1.1.12-1.el7.noarch ovirt-ansible-manageiq-1.1.14-1.el7.noarch ovirt-engine-wildfly-17.0.1-1.el7.x86_64 ovirt-ansible-hosted-engine-setup-1.0.32-1.el7.noarch ovirt-imageio-common-1.5.3-0.el7.x86_64 ovirt-imageio-proxy-1.5.3-0.el7.noarch python2-ovirt-setup-lib-1.2.0-1.el7.noarch ovirt-vmconsole-proxy-1.0.7-2.el7.noarch ovirt-engine-setup-base-4.3.10.4-1.el7.noarch ovirt-engine-setup-plugin-cinderlib-4.3.10.4-1.el7.noarch ovirt-engine-extensions-api-impl-4.3.10.4-1.el7.noarch ovirt-release43-4.3.10-1.el7.noarch ovirt-engine-backend-4.3.10.4-1.el7.noarch ovirt-engine-tools-4.3.10.4-1.el7.noarch ovirt-web-ui-1.6.0-1.el7.noarch ovirt-ansible-cluster-upgrade-1.1.14-1.el7.noarch ovirt-cockpit-sso-0.1.1-1.el7.noarch ovirt-engine-ui-extensions-1.0.10-1.el7.noarch ovirt-engine-setup-plugin-ovirt-engine-common-4.3.10.4-1.el7.noarch ovirt-engine-4.3.10.4-1.el7.noarch ovirt-ansible-repositories-1.1.5-1.el7.noarch ovirt-engine-extension-aaa-jdbc-1.1.10-1.el7.noarch ovirt-host-deploy-java-1.8.5-1.el7.noarch ovirt-engine-dwh-4.3.8-1.el7.noarch ovirt-engine-api-explorer-0.0.5-1.el7.noarch ovirt-guest-agent-common-1.0.16-1.el7.noarch ovirt-engine-setup-4.3.10.4-1.el7.noarch ovirt-engine-dbscripts-4.3.10.4-1.el7.noarch In /var/log/ovirt-engine/engine.log: 2020-07-24 09:38:44,472+03 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (EE-ManagedThreadFactory-engineScheduled-Thread-91) [] VM '18f6bb79-ba9b-4a0e-bcb2-b4ef4904ef99'(rtb-stagedsw02-ovh) move d from 'Up' --> 'Paused' 2020-07-24 09:38:44,493+03 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engineScheduled-Thread-91) [] EVENT_ID: VM_PAUSED(1,025), VM rtb-stagedsw02-ovh has been paused. In /var/log/vdsm/vdsm.log 2020-07-24 09:38:42,771+0300 INFO (libvirt/events) [virt.vm] (vmId='18f6bb79-ba9b-4a0e-bcb2-b4ef4904ef99') CPU stopped: onSuspend (vm:6100) 2020-07-24 09:38:44,328+0300 INFO (jsonrpc/1) [api.host] FINISH getAllVmIoTunePolicies return={'status': {'message': 'Done', 'code': 0}, 'io_tune_policies_dict': {'4d9519f6-1ab9-4032-8fdf-4c6118531544': {'poli cy': [], 'current_values': [{'ioTune': {'write_bytes_sec': 0L, 'total_iops_sec': 0L, 'read_iops_sec': 0L, 'read_bytes_sec': 0L, 'write_iops_sec': 0L, 'total_bytes_sec': 0L}, 'path': '/rhev/data-center/mnt/glust erSD/10.0.11.107:_vmstore02/16c5070c-cc5f-4595-965f-66838c7c17a5/images/e1cfb9ec-39d8-416d-9f5f-0b54765301d4/8f95d60d-931b-4764-993c-ba9373efe361', 'name': 'sda'}]}, 'b031a269-6bcd-40b7-9737-e47112a54b3a': {'po licy': [], 'current_values': [{'ioTune': {'write_bytes_sec': 0L, 'total_iops_sec': 0L, 'read_iops_sec': 0L, 'read_bytes_sec': 0L, 'write_iops_sec': 0L, 'total_bytes_sec': 0L}, 'path': '/rhev/data-center/mnt/glu sterSD/10.0.11.101:_vmstore01/5e05fed3-448b-4f86-b5ba-004982194c90/images/9c3cc7a0-254e-4756-91b6-fb54e21abf38/71dd8024-8aec-46da-a80f-34260655e929', 'name': 'sda'}, {'ioTune': {'write_bytes_sec': 0L, 'total_io ps_sec': 0L, 'read_iops_sec': 0L, 'read_bytes_sec': 0L, 'write_iops_sec': 0L, 'total_bytes_sec': 0L}, 'path': '/rhev/data-center/mnt/glusterSD/10.0.11.101:_vmstore01/5e05fed3-448b-4f86-b5ba-004982194c90/images/ 3e3a5064-5fe1-40c0-81f5-44f1a3a4d503/13549972-82de-4746-aeea-3e1531f9c180', 'name': 'sdb'}]}, 'b5fad17c-fa9d-4a80-99e7-6f86e6e19c9b': {'policy': [], 'current_values': [{'ioTune': {'write_bytes_sec': 0L, 'total_ iops_sec': 0L, 'read_iops_sec': 0L, 'read_bytes_sec': 0L, 'write_iops_sec': 0L, 'total_bytes_sec': 0L}, 'path': '/rhev/data-center/mnt/glusterSD/10.0.11.107:_vmstore02/16c5070c-cc5f-4595-965f-66838c7c17a5/image s/15ce6cb0-6f06-4a31-92d8-b6e1bcabf3bc/613de344-d1ad-49aa-a2d0-d60ca9eb7cd3', 'name': 'sda'}]}, '18f6bb79-ba9b-4a0e-bcb2-b4ef4904ef99': {'policy': [], 'current_values': [{'ioTune': {'write_bytes_sec': 0L, 'tota l_iops_sec': 0L, 'read_iops_sec': 0L, 'read_bytes_sec': 0L, 'write_iops_sec': 0L, 'total_bytes_sec': 0L}, 'path': u'/rhev/data-center/mnt/glusterSD/10.0.11.107:_vmstore02/16c5070c-cc5f-4595-965f-66838c7c17a5/im ages/7978e2db-c560-4315-a775-223f1b13ae31/d927eea8-e588-449e-b07b-c845d15b082e', 'name': 'sda'}, {'ioTune': {'write_bytes_sec': 0L, 'total_iops_sec': 0L, 'read_iops_sec': 0L, 'read_bytes_sec': 0L, 'write_iops_s ec': 0L, 'total_bytes_sec': 0L}, 'path': u'/rhev/data-center/mnt/glusterSD/10.0.11.107:_vmstore02/16c5070c-cc5f-4595-965f-66838c7c17a5/images/b925dc2e-17ba-470d-a9be-cb96d4ef1f0d/951d9712-7160-4f88-a838-970aec8 2b3ea', 'name': 'sdb'}]}}} from=::1,34598 (api:54) 2020-07-24 09:38:49,747+0300 WARN (qgapoller/1) [virt.periodic.VmDispatcher] could not run <function <lambda> at 0x7fe5c84de6e0> on ['18f6bb79-ba9b-4a0e-bcb2-b4ef4904ef99'] (periodic:289) In /var/log/libvirt/qemu/rtb-stagedsw03-ovh.log KVM: entry failed, hardware error 0x80000021 If you're running a guest on an Intel machine without unrestricted mode support, the failure can be most likely due to the guest entering an invalid state for Intel VT. For example, the guest maybe running in big real mode which is not supported on less recent Intel processors. EAX=00001000 EBX=43117da8 ECX=0000000c EDX=00000121 ESI=00000003 EDI=17921000 EBP=43117cb0 ESP=43117c98 EIP=00008000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=1 HLT=0 ES =0000 00000000 ffffffff 00809300 CS =9b00 7ff9b000 ffffffff 00809300 SS =0000 00000000 ffffffff 00809300 DS =0000 00000000 ffffffff 00809300 FS =0000 00000000 ffffffff 00809300 GS =0000 00000000 ffffffff 00809300 LDT=0000 00000000 000fffff 00000000 TR =0040 001ce000 0000206f 00008b00 GDT= 001cc000 0000007f IDT= 00000000 00000000 CR0=00050032 CR2=17921000 CR3=2b92a003 CR4=00000000 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000fffe0ff0 DR7=0000000000000400 EFER=0000000000000000 Code=ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff <ff> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

2 1