Bug 1663212

Summary: [docs] Q35: VM failed to boot after changing BIOS type from BIOS to UEFI.
Product: [oVirt] ovirt-engine Reporter: Nisim Simsolo <nsimsolo>
Component: DocumentationAssignee: bugs <bugs>
Status: CLOSED DUPLICATE QA Contact: Lukas Svaty <lsvaty>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.3.0CC: adahms, bugs, nsimsolo, rbarry, royoung, sgoodman
Target Milestone: ovirt-4.4.1Flags: pm-rhel: ovirt-4.4?
pm-rhel: ovirt-4.5?
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-03 14:38:59 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:
Attachments:
Description Flags
dumpxml of VM with UEFI
none
dumpxml of VM with BIOS
none
vdsm.log
none
engine.log none

Description Nisim Simsolo 2019-01-03 12:40:30 UTC 
Description of problem:
After changin VM BIOS type from default to "Q35 Chipset with UEFI BIOS", the VM failed to run with the next message (in console):
BdsDxe: No bootable option or device was found.

Version-Release number of selected component (if applicable):
ovirt-engine-4.3.0-0.4.master.20181230173049.gitef04cb4.el7
vdsm-4.30.4-81.gitad6147e.el7.x86_64
libvirt-client-4.5.0-10.el7_6.3.x86_64
qemu-kvm-ev-2.12.0-18.el7_6.1.1.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Run RHEL 7.6 VM with default BIOS and verify VM is running.
2. Change BIOS type and custom emulated machine pc-i440fx-rhel7.6.0 to "Q35 Chipset with UEFI BIOS" and custom emulated machine to pc-q35-rhel7.6.0
3. Run VM.

Actual results:
VM failed to boot.

Expected results:
VM should boot normally.

Additional info:
dumpxml of both VMs attached. vdsm and engine logs attached.
Comment 1 Nisim Simsolo 2019-01-03 13:27:24 UTC 
Created attachment 1518139 [details]
dumpxml of VM with UEFI
Comment 2 Nisim Simsolo 2019-01-03 13:28:01 UTC 
Created attachment 1518140 [details]
dumpxml of VM with BIOS
Comment 3 Nisim Simsolo 2019-01-03 13:28:28 UTC 
Created attachment 1518141 [details]
vdsm.log
Comment 4 Nisim Simsolo 2019-01-03 13:28:46 UTC 
Created attachment 1518142 [details]
engine.log
Comment 5 Nisim Simsolo 2019-01-03 13:29:25 UTC 
OVMF build: OVMF-20180508-3.gitee3198e672e2.el7.noarch
Comment 6 Ryan Barry 2019-01-04 01:02:25 UTC 
To be honest, I can't think of a use case where this would be a necessary or desirable operation, and I'm ok saying that we won't support it. Deferring
Comment 7 Michal Skrivanek 2019-01-04 09:01:03 UTC 
it's worth a documentation of some sorts. Maybe not even a popup, just s doc note that switching it for existing VMs will fail in many cases
Comment 8 Ryan Barry 2019-01-04 13:41:47 UTC 
Fair point
Comment 9 Ryan Barry 2019-01-21 14:54:00 UTC 
Re-targeting to 4.3.1 since it is missing a patch, an acked blocker flag, or both
Comment 10 Ryan Barry 2019-01-21 15:28:09 UTC 
This is not a supported operation, but we should include a note in the documentation indicating that this is expected behavior
Comment 13 Ryan Barry 2019-05-15 03:28:17 UTC 
Steve, did this it out for GA?