Created attachment 1387819 [details] engine & vdsm logs from automation test Description of problem: can't start High-Performance VM in PPC environment Version-Release number of selected component (if applicable): ovirt-engine-setup-plugin-ovirt-engine-4.2.1.3 How reproducible: Steps to Reproduce: 1.Edit VM / Optimized For/ High Performance 2.Run VM 3. Actual results: Can't add USB input device. USB bus is disabled. 2018-01-28 00:49:45,785+02 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (ForkJoinPool-1-worker-1) [] add VM 'a8ce5960-4ab3-4b71-b115-7ff01aab1da1'(golden_env_mixed_virtio_1_0) to rerun treatment 2018-01-28 00:49:45,790+02 ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmsMonitoring] (ForkJoinPool-1-worker-1) [] Rerun VM 'a8ce5960-4ab3-4b71-b115-7ff01aab1da1'. Called from VDS 'host_mixed_1' 2018-01-28 00:49:45,837+02 WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-989) [] EVENT_ID: USER_INITIATED_RUN_VM_FAILED(151), Failed to run VM golden_env_mixed_virtio_1_0 on Host host_mixed_1. Expected results: VM started Additional info: bug found in automation environment jenkins-vm-15.qa.lab.tlv.redhat.com. logs attached
LibvirtVmXmlBuilder::writeInput() needs a fix Perhaps just run without a mouse altogether
(In reply to Michal Skrivanek from comment #1) > LibvirtVmXmlBuilder::writeInput() needs a fix > Perhaps just run without a mouse altogether Right, the same way as done for disabling Tablet devices in case of HP VMs: https://github.com/oVirt/ovirt-engine/blob/47d43aa114a3c89c751466dea044bbcc2bb2d5b9/backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/builder/vminfo/LibvirtVmXmlBuilder.java#L2260
Tested on PPC BUILD 4.2.2-4 (jenkins-vm-15.lab.eng.tlv2.redhat.com). the packages on host : vdsm-hook-vhostmd-4.20.20-1.el7ev.noarch vdsm-hook-openstacknet-4.20.20-1.el7ev.noarch vdsm-jsonrpc-4.20.20-1.el7ev.noarch vdsm-hook-ethtool-options-4.20.20-1.el7ev.noarch vdsm-client-4.20.20-1.el7ev.noarch vdsm-yajsonrpc-4.20.20-1.el7ev.noarch vdsm-common-4.20.20-1.el7ev.noarch vdsm-http-4.20.20-1.el7ev.noarch vdsm-hook-vfio-mdev-4.20.20-1.el7ev.noarch vdsm-api-4.20.20-1.el7ev.noarch vdsm-python-4.20.20-1.el7ev.noarch vdsm-4.20.20-1.el7ev.ppc64le vdsm-hook-fcoe-4.20.20-1.el7ev.noarch vdsm-network-4.20.20-1.el7ev.ppc64le vdsm-hook-vmfex-dev-4.20.20-1.el7ev.noarch Steps: 1.Create VM, 2.Configure High Performance. 3.Run Actual Result:from engine.log: "VM test_hp2 is down with error. Exit message: unsupported configuration: CPU cache specification is not supported for 'ppc64' architecture." Expected: VM started w/o error. engine log attached
Created attachment 1407505 [details] look in engine.log line 8051
(In reply to Polina from comment #3) > Tested on PPC BUILD 4.2.2-4 (jenkins-vm-15.lab.eng.tlv2.redhat.com). the > packages on host : > Steps: 1.Create VM, 2.Configure High Performance. 3.Run > Actual Result:from engine.log: "VM test_hp2 is down with error. Exit > message: unsupported configuration: CPU cache specification is not supported > for 'ppc64' architecture." > Expected: VM started w/o error. It seems that enabling CPU cache layer 3 is not supported by libvirt for that ppc host. Can you please check which libvirt version is installed on host and also attach vdsm+libvirt logs? Thanks
It seems according to [1] that the cache element in domain xml which describes the virtual CPU caching is not supported for non x86 architecture, and therefore this line is not supported for ppc: <cpu> .... <cache level="3" mode="emulate"/> </cpu> Meaning that we should disable CPU cache layer 3 for HP vms in case of ppc arch. [1] https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_domain.c#l3188 Francesco, can you please approve this or am I missing something? thanks.
(In reply to Sharon Gratch from comment #6) > It seems according to [1] that the cache element in domain xml which > describes the virtual CPU caching is not supported for non x86 architecture, > and therefore this line is not supported for ppc: > <cpu> > .... > <cache level="3" mode="emulate"/> > </cpu> > > Meaning that we should disable CPU cache layer 3 for HP vms in case of ppc > arch. > > [1] > https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_domain.c#l3188 > > Francesco, can you please approve this or am I missing something? thanks. Also, I thought that in RHEL 7.4 and beyond this is not needed to be explicitly set. Martin?
(In reply to Sharon Gratch from comment #6) > It seems according to [1] that the cache element in domain xml which > describes the virtual CPU caching is not supported for non x86 architecture, > and therefore this line is not supported for ppc: > <cpu> > .... > <cache level="3" mode="emulate"/> > </cpu> > > Meaning that we should disable CPU cache layer 3 for HP vms in case of ppc > arch. > > [1] > https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_domain.c#l3188 > > Francesco, can you please approve this or am I missing something? thanks. Yes Sharon, you seem to be right. The documentation is a bit vague, but it seems that we should use the <cache> element only on x86_64. So, neither on PPC or in s390. Per https://libvirt.org/formatdomain.html#elementsCPU is not that bad, the hypervisor driver is supposed to pick a good default if we don't set explicit values. It is not uncommon that new libvirt features appear on x86_64 + qemu, and after a while they appear also on other arches/hypervisor drivers. Feel free to file a libvirt documentation bug if you wish.
I believe Yaniv is right - the CPU cache was meant to be set pre-7.4 and migrated to default later. It'd be worth verifying that it is the case though.
Is this on track to 4.2.2? If not, please defer to 4.2.3.
(In reply to Yaniv Kaul from comment #10) > Is this on track to 4.2.2? If not, please defer to 4.2.3. yes, it is on track to 4.2.2
The problem is verified on rhv-release-4.2.3-2-001.noarch.
This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.2 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.
Popped up again in RHV IPI use case, where it creates a VM using the API, from blank template, set type to high_performance. ovirt 4.4.2, cluster version 4.3, vm console type is spice+vnc. Setting the console to vnc works around this. 2020-08-03 10:37:40,796+03 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (ForkJoinPool-1-worker-31) [] VM 'a50993e0-7161-4969-ae01-2ad8fdbef02f'(catapult-znhpr-master-2) move d from 'WaitForLaunch' --> 'Down' 2020-08-03 10:37:40,810+03 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ForkJoinPool-1-worker-31) [] EVENT_ID: VM_DOWN_ERROR(119), VM catapult-znhpr-master-2 is down with error. Exit message: unsupported configuration: Can't add USB input device. USB bus is disabled. Reopen or a new bug?
ppc64le doesn't have SPICE. You need to set correct console type to only VNC
(In reply to Roy Golan from comment #16) > Popped up again in RHV IPI use case, where it creates a VM using the API, > from blank template, set type to high_performance. > > ovirt 4.4.2, cluster version 4.3, vm console type is spice+vnc. > > Setting the console to vnc works around this. > > > 2020-08-03 10:37:40,796+03 INFO > [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] > (ForkJoinPool-1-worker-31) [] VM > 'a50993e0-7161-4969-ae01-2ad8fdbef02f'(catapult-znhpr-master-2) move > d from 'WaitForLaunch' --> 'Down' > 2020-08-03 10:37:40,810+03 ERROR > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > (ForkJoinPool-1-worker-31) [] EVENT_ID: VM_DOWN_ERROR(119), VM > catapult-znhpr-master-2 > is down with error. Exit message: unsupported configuration: Can't add USB > input device. USB bus is disabled. > > > Reopen or a new bug? This bug is specific for PPC. I guess by the spice+vnc you are not on PPC. Right?