Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Description of problem: After Launching a VM with the Custom Emulation Machine Type set to a Q35 chipset and the Bios Type to Legacy Bios Type, shutting down the VM and then re-Launching the VM, the VM fails to launch. Here is the first run which succeeds: https://pastebin.com/AbR53CSL Lines 1 – 125 – domain xml sent from the engine Lines 138 – 359 – domain xml received by the engine (note the pci controls received and not sent) Line 365 verifies the VM is running Here is the second run after shutdown which fails: https://pastebin.com/CwD3tvpH Lines 1 – 132 – domain xml sent from the engine Lines 162 – 292 – domain xml received by the engine Line 302 – Error message from libvirt within the engine log Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Create a VM with: A. The Custom Emulation Machine Type set to a Q35 Chipset B. The Bios Type to Legacy Bios Type. 2. Launch the VM until it is running. 3. Shut down the VM 4. Launch the VM again Actual results: The VM fails to launch with the following error [1] Expected results: The VM will run every time. Additional info: [1] 2020-03-10 17:44:13,107+02 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ForkJoinPool-1-worker-1) [] EVENT_ID: VM_DOWN_ERROR(119), VM VMTest is down with error. Exit message: XML error: Invalid PCI address 0000:04:00.0. slot must be >= 1.
Created attachment 1670313 [details] Logs showing the initial Launch succeeding
Created attachment 1670314 [details] Log snippet showing subsequent Launches failing
(In reply to Steven Rosenberg from comment #1) > Description of problem: > > After Launching a VM with the Custom Emulation Machine Type set to a Q35 > chipset and the Bios Type to Legacy Bios Type, > shutting down the VM and then re-Launching the VM, the VM fails to launch. but that's only for the first run, isn't it?
(In reply to Michal Skrivanek from comment #4) > (In reply to Steven Rosenberg from comment #1) > > Description of problem: > > > > After Launching a VM with the Custom Emulation Machine Type set to a Q35 > > chipset and the Bios Type to Legacy Bios Type, > > shutting down the VM and then re-Launching the VM, the VM fails to launch. > > but that's only for the first run, isn't it? It only succeeds on the first run as per the logs in Comment 2. After the first shutdown and restart it fails as per Comment 3. Further attempts continue to fail unless the Bios Type and Emulation Machine Type are synchronized. The fix is not only fixing the Default when the Host comes Up the first time, but also when the user changes either Bios Type, Emulation Machine Type, or both to mixed chip set values.
*** Bug 1817053 has been marked as a duplicate of this bug. ***
we don't allow mixing, but patches in this bug resolved the unintentional mix up that happened in the code
Verified: ovirt-engine-4.4.1.1-0.5.el8ev vdsm-4.40.17-1.el8ev.x86_64 libvirt-daemon-6.0.0-22.module+el8.2.1+6815+1c792dc8.x86_64 qemu-kvm-4.2.0-22.module+el8.2.1+6758+cb8d64c2.x86_64 Verification scenario: 1. On an existing cluster (default) Run/power off 10 times a VM (default cluster value should be Q35 chipset with legacy BIOS) 2. Verify VM is running with no errors.
Cause: Consequences of Q35 additions that caused regressions including changes of the default Emulation Machine Type. Consequence: Mixing of incompatible Bios Types with Emulation Machine Types cause failures. Workaround (if any): User is required to provide the proper Bios Type and Emulation Machine Type. Result: The Bios Type and the Emulation Machine Type settings are considered advanced features to be set properly by the user. In addition, default values at the front and back end were adjusted to ensure adding a Host to a new cluster with auto-detect will set the Bios Type accordingly.
This bugzilla is included in oVirt 4.4.1 release, published on July 8th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.1 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.