Bug 1663212 - [docs] Q35: VM failed to boot after changing BIOS type from BIOS to UEFI.
Summary: [docs] Q35: VM failed to boot after changing BIOS type from BIOS to UEFI.
Keywords:
Status: CLOSED DUPLICATE of bug 1613496
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Documentation
Version: 4.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ovirt-4.4.1
: ---
Assignee: bugs@ovirt.org
QA Contact: Lukas Svaty
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-01-03 12:40 UTC by Nisim Simsolo
Modified: 2020-06-26 16:30 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-03 14:38:59 UTC
oVirt Team: Virt
Embargoed:
pm-rhel: ovirt-4.4?
pm-rhel: ovirt-4.5?

Attachments (Terms of Use)
dumpxml of VM with UEFI (11.88 KB, text/plain)
2019-01-03 13:27 UTC, Nisim Simsolo 		no flags Details
dumpxml of VM with BIOS (9.56 KB, text/plain)
2019-01-03 13:28 UTC, Nisim Simsolo 		no flags Details
vdsm.log (1.16 MB, text/plain)
2019-01-03 13:28 UTC, Nisim Simsolo 		no flags Details
engine.log (621.62 KB, text/plain)
2019-01-03 13:28 UTC, Nisim Simsolo 		no flags Details
View All

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?
Note You need to log in before you can comment on or make changes to this bug.