Description of problem: - importing VMware VMs with EFI BIOS and secure boot enabled are converted to "Q35 chipset with UEFI BIOS" instead of being converted to "Q35 chipset with SecureBoot". - In such case, imported VMs are running, but without secured boot. - Possible workaround is to manually change VM BIOS type from "Q35 chipset with UEFI BIOS" to "Q35 chipset with SecureBoot" before running the VM. - This issue was tested with operating system type that works OOB when using secure boot (Windows 10 and Fedora 28). Version-Release number of selected component (if applicable): rhvm-4.3.5.2-0.1.el7 vdsm-4.30.22-1.el7ev.x86_64 virt-v2v-1.40.2-5.el7.x86_64 libvirt-4.5.0-23.el7.x86_64 qemu-kvm-rhev-2.12.0-33.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1. Import from VMware Windows 10 VM and Fedora 28 VM with EFI BIOS and secure boot enabled. 2. After import completion, from WebAdmin -> Compute -> VMs -> edit VM -> system: observe VMs BIOS type. 3. Run VMs and verify VMs are running with secure boot. 4. Work around: power off VMs and change BIOS type to "Q35 chipset with SecureBoot". Run VMs. Actual results: 2. BIOS type is "Q35 chipset with UEFI BIOS" instead of "Q35 chipset with SecureBoot" on both VMs. 3. Both VMs are running without secure boot. An example from Windows PowerShell: PS C:\Confirm-SecureBootUEFI False 4. VMs are now running with functional secure boot. Expected results: Importing VMware VMs with EFI BIOS and secure boot should be converted to "Q35 chipset with SecureBoot" Additional info: Import logs, vdsm.log and engine.log attached. engine.log Windows import started at 2019-06-30 18:15:50,461+03, Fedora import started at 2019-06-30 13:36:05,056+03
Created attachment 1586959 [details] engine.log
Created attachment 1586960 [details] vdsb.log 1
Created attachment 1586961 [details] vdsb.log 2
Created attachment 1586962 [details] import.log of Fedora VM with secure boot enabled
Created attachment 1586963 [details] import.log of Windows VM with secure boot enabled
AFAICT virt-v2v only supports i440fx+seabios and q35+UEFI. Rich, are there any plans to support q35+UEFI+SecureBoot or q35+seabios? The latter would be useful for future when we move to q35+seabios as a default for new VMs (though for v2v I guess it makes sense to parametrize it)
Not really. There is preliminary support for SecureBoot for some output methods, see eg: https://github.com/libguestfs/libguestfs/blob/f02c0cb552e0cf3a82a9447791db4c430426d569/v2v/output_qemu.ml#L61 although all it really does is check if the target has a UEFI binary which requires SecureBoot. What's needed to make it work end to end is to model the information about secureboot from the source hypervisor and then write the relevant OVF etc to the target. Several things make this complicated: - I don't know if VMware metadata tells us reliably if the guest is using secureboot on the source, or if there's some other way to intuit that from the guest - We're rebuilding the initramfs which likely breaks secureboot - For Windows we're installing guest drivers which probably breaks secureboot too - It's unclear if it's even possible to port a secureboot guest from one hypervisor to another as that's exactly the kind of thing which secureboot is supposed to prevent. The long and the short is this isn't going to happen any time soon unless someone who understands how secureboot works can contribute patches.
(In reply to Richard W.M. Jones from comment #7) > Not really. There is preliminary support for SecureBoot for some output > methods, see eg: > > https://github.com/libguestfs/libguestfs/blob/ > f02c0cb552e0cf3a82a9447791db4c430426d569/v2v/output_qemu.ml#L61 > > although all it really does is check if the target has a UEFI binary which > requires > SecureBoot. > > What's needed to make it work end to end is to model the information about > secureboot > from the source hypervisor and then write the relevant OVF etc to the target. > > Several things make this complicated: > > - I don't know if VMware metadata tells us reliably if the guest is using > secureboot > on the source, or if there's some other way to intuit that from the guest > > - We're rebuilding the initramfs which likely breaks secureboot > > - For Windows we're installing guest drivers which probably breaks > secureboot too > > - It's unclear if it's even possible to port a secureboot guest from one > hypervisor > to another as that's exactly the kind of thing which secureboot is > supposed to > prevent. > > The long and the short is this isn't going to happen any time soon unless > someone > who understands how secureboot works can contribute patches. What is the status of this issue and do we have a time frame for addressing this issue?
There's no status because we don't have enough developers working on virt-v2v for all the things that need to be done. Patches welcome. About the difficulty of actually implementing this (I think it's probably not feasible), see comment 7.
*** Bug 1855001 has been marked as a duplicate of this bug. ***
Copying https://bugzilla.redhat.com/show_bug.cgi?id=1855001#c4: ok, so the logic we've introduced in CompatibilityVersionUpdater should be adjusted - if the given VM is set with Q35_OVMF, it should remain with Q35_OVMF regardless of the target cluster
(In reply to Arik from comment #13) > Copying https://bugzilla.redhat.com/show_bug.cgi?id=1855001#c4: > ok, so the logic we've introduced in CompatibilityVersionUpdater should be > adjusted - > if the given VM is set with Q35_OVMF, it should remain with Q35_OVMF > regardless of the target cluster In my opinion for VMs coming from older cluster, we should switch them to cluster default (BZ 1846954). If the VM comes from 4.4 cluster, we should have the configured BIOS type.
Reassigned, same behavior as described in https://bugzilla.redhat.com/show_bug.cgi?id=1726558#c0 Version: ovirt-engine-4.4.3.5-0.5.el8ev vdsm-4.40.32-1.el8ev.x86_64 virt-v2v-1.42.0-6.module+el8.3.0+7898+13f907d5.x86_64 qemu-kvm-5.1.0-10.module+el8.3.0+8254+568ca30d.x86_64 libvirt-daemon-6.6.0-6.module+el8.3.0+8125+aefcf088.x86_64
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
engine.log, virt-v2v.log and vdsm.log (import started at 2020-10-04 10:35:12,440+0300) attached.
Created attachment 1718745 [details] reassigned: vdsm.log
Created attachment 1718748 [details] reassinged: virt-v2v import.log
Created attachment 1718749 [details] reassigned: engine.log
Created attachment 1731976 [details] guest-bios-cluster-bios-not-match.png
Being closed as not a bug on 4.4.3-1, re-targeting to 4.4.3-1 accordingly.