Bug 1894454

Summary: VM fails to boot when moved to a cluster with a different chipset
Product: Red Hat Enterprise Virtualization Manager Reporter: Miguel Martin <mmartinv>
Component: ovirt-engineAssignee: Arik <ahadas>
Status: CLOSED ERRATA QA Contact: Nisim Simsolo <nsimsolo>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.4.1CC: ahadas, michal.skrivanek, nsimsolo, sgoodman
Target Milestone: ovirt-4.4.4-1   
Target Release: 4.4.4   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ovirt-engine-4.4.4.7 Doc Type: Bug Fix
Doc Text:
Previously when a virtual machine moved from one cluster to another, resulting in the virtual machine's chipset changing, then the virtual machine did not run successfully. With this release, when a virtual machine moves from one cluster to another, it's devices and chipset are automatically updated, and the virtual machine runs successfully.
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-02-02 14:00:17 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Miguel Martin 2020-11-04 10:22:08 UTC
Description of problem:

After moving a VM from one cluster (4.3 compatibility version) to another (4.4 compatibility version) the VM fails to boot.


Version-Release number of selected component (if applicable):
ovirt-engine-4.4.1.10-0.1.el8ev.noarch

How reproducible:
Always


Steps to Reproduce:
1. Stop the VM running in a cluster with 4.3 compatibility version
2. Edit the VM and change the cluster to one with 4.4 compatibility version
3. Save the VM configuration
4. Try to start the VM

Actual results:
The VM fails to start with the following error:
~~~
internal error: Bus 0 must be PCI for integrated PIIX3 USB or IDE controllers (code=1) (vm:1629)
~~~

Expected results:
The VM starts normally

Comment 3 Arik 2020-11-05 08:27:32 UTC
Yet another flow where the VM is not adjusted to Q35 - this time moving VMs between clusters

Comment 4 Sandro Bonazzola 2020-12-18 15:35:02 UTC
This bug is in POST status for ovirt 4.4.4. We are now in blocker only phase, please either mark this as a blocker or please re-target.

Comment 10 Nisim Simsolo 2021-01-12 11:38:08 UTC
Verification builds:
ovirt-engine-4.4.4.7-0.1.el8ev
vdsm-4.40.40-1.el8ev.x86_64
libvirt-daemon-6.6.0-7.module+el8.3.0+8424+5ea525c5.x86_64
qemu-kvm-5.1.0-14.module+el8.3.0+8438+644aff69.x86_64

Verification scenario:
1. Run VM with i440FX chipset with BIOS.
2. Verify VM is running, verify VM is running with correct devices.
3. Power off VM and change chipset to Q35 chipset with BIOS.
4. Run VM
5. Verify VM is running, verify VM is running with correct devices (Q35 devices).
6. Repeat steps 1-5 using the same VM few times more.

Comment 13 Arik 2021-01-31 15:30:22 UTC
I'm afraid the previous test didn't reflect the change properly- it has nothing to do with the compatibility version.
If the VM was set with chipset X and changes to chipset Y when its cluster changes, then the device addresses and unmanaged devices are cleared.
For this to happen, the VM has to be set without custom bios type, i.e., with bios type = cluster-default, and the chipset of the cluster has to change from i440fx to q35 or vice versa.
Steve, could you please update the doc?

Comment 16 errata-xmlrpc 2021-02-02 14:00:17 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: RHV-M (ovirt-engine) 4.4.z security, bug fix, enhancement upd[ovirt-4.4.4] 0-day), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:0383