Bug 1726558

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.