Created attachment 1260877 [details] engine log It is possible to create a new VM based on some existing template. As well as, "admin" is able to change any parameter for new VM. If admin changes "Video type" from QXL to VGA then created VM fails to start. ovirt-engine-4.1.1.3-0.1.el7.noarch How reproducible: always Steps to Reproduce: 1. Login to Admin portal. 2. Create a template. Video type must be QXL. Guest OS doesn't matter (Linux/Windows). 3. Start creation of a new VM. 4. Change template from "Blank" to template created at step #2. 5. Go to "Console" tab. Change "Video type" == "VGA". 6. Confirm creation of new VM. (OK) 7. Start created VM. Actual results: Created VM fails to start.
@Andrei, can you please provide more complete engine log - and not just the immediate snippet? Thank you.
Created attachment 1261271 [details] full log
Note for reproduction it is critical that the original template has not only QXL video type but also the USB Support set to ENABLED, since this was a bug related to treatment of USB controllers when changing the video type.
*** Bug 1431246 has been marked as a duplicate of this bug. ***
This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.
Is it possible that https://bugzilla.redhat.com/show_bug.cgi?id=1427104#c20 also related to this bug? I was not able to start VM even without changing it's video.
the fix seems to fix other upgrade-related problems in this area, the fix is low risk, better backport it to 4.1.1
Created attachment 1264268 [details] stacktrace.txt It would be nice also test following scenario: 1. Change Blank template "USB Support" to Enabled (default is Disabled) 2. Create a VM using REST api and customize usb support to enable it. POST /vms <vm> <name>cute-vm</name> <template> <name>Blank</name> </template> <cluster> <name>Default</name> </cluster> <usb> <enabled>false</enabled> <type>native</type> </usb> <!-- add bootable device customization --> </vm> 3. Run the vm Actual result: It fails in step 2. with stacktrace in attachment Expected result: VM boots
(In reply to Michal Skrivanek from comment #7) > the fix seems to fix other upgrade-related problems in this area, the fix is > low risk, better backport it to 4.1.1 It seems to have missed 4.1.1, setting to 4.1.2 for the time being. If it can make it to 4.1.1-1, even better.
JAkub, what about http://gerrit.ovirt.org/74266 ?
http://gerrit.ovirt.org/74266 and its 4.1 backport http://gerrit.ovirt.org/74338 will remain connected to this bug.
Works for me on these components on hosts: ovirt-imageio-daemon-1.0.0-0.el7ev.noarch ovirt-setup-lib-1.1.0-1.el7ev.noarch ovirt-imageio-common-1.0.0-0.el7ev.noarch sanlock-3.4.0-1.el7.x86_64 ovirt-vmconsole-1.0.4-1.el7ev.noarch vdsm-4.19.10-1.el7ev.x86_64 ovirt-hosted-engine-ha-2.1.0.5-1.el7ev.noarch ovirt-host-deploy-1.6.3-1.el7ev.noarch qemu-kvm-rhev-2.6.0-28.el7_3.8.x86_64 ovirt-vmconsole-host-1.0.4-1.el7ev.noarch ovirt-hosted-engine-setup-2.1.0.5-1.el7ev.noarch libvirt-client-2.0.0-10.el7_3.5.x86_64 mom-0.5.9-1.el7ev.noarch ovirt-engine-sdk-python-3.6.9.1-1.el7ev.noarch Linux version 3.10.0-514.16.1.el7.x86_64 (mockbuild.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Fri Mar 10 13:12:32 EST 2017 Linux 3.10.0-514.16.1.el7.x86_64 #1 SMP Fri Mar 10 13:12:32 EST 2017 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux Server release 7.3 (Maipo) On engine: rhevm-doc-4.1.0-2.el7ev.noarch rhev-guest-tools-iso-4.1-4.el7ev.noarch rhevm-4.1.1.6-0.1.el7.noarch rhevm-branding-rhev-4.1.0-1.el7ev.noarch rhevm-setup-plugins-4.1.1-1.el7ev.noarch rhevm-dependencies-4.1.1-1.el7ev.noarch Linux version 3.10.0-514.6.1.el7.x86_64 (mockbuild.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Sat Dec 10 11:15:38 EST 2016 Linux 3.10.0-514.6.1.el7.x86_64 #1 SMP Sat Dec 10 11:15:38 EST 2016 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux Server release 7.3 (Maipo)
Created attachment 1266651 [details] Engine log from ovirt-engine-4.1.1.6-1.el7.centos.noarch failing I get the 'At most one USB controller expected' error even with ovirt-engine 4.1.1.6. I have a number of stateless VMs for testing. They are started and stopped several times a day, and has been working fine even after upgrading to oVirt 4.1.1. Today however I needed to update the contents of the VMs, so I did the following: * Uncheck the Stateless box and save - ok. * Start VMs - ok. * Shutdown VMs - ok. * Create snapshot - ok. * Check the Stateless box and save - FAIL with attached log. Now even if I do not change anything when editing the VM in the engine GUI I get the same internal error when clicking Ok, and just doing: update vm vmname in ovirt-shell produces the same. I have not changed the "Blank" template that the VMs are based on for several months, but it has been changed in the past.
Trying to clone the VM from the newly created snapshot fails with the same error. Cloning from a snapshot taken back in October works fine.
I did not worked with stateless VMs. I think this is different issue as reproduction steps are different from the originally described. Cloning this bug to new one.