Description of problem: The Fedora Cloud WG recently changed to offering hybrid boot cloud images. This was done as the start of a longer-term effort to engage with the community and partners to boot Fedora images with UEFI. As part of this effort, we'd like to have the virt stack default to offering UEFI for VMs (with a CSM for BIOS backward compatibility if possible). It would be appreciated if virt-manager defaulted to creating VMs with UEFI+CSM for "fedora", "unknown linux" and other similar things. Additional info: The full discussion about this is in the Fedora Cloud WG meeting logs here: https://meetbot.fedoraproject.org/teams/fedora_cloud_meeting/fedora_cloud_meeting.2021-08-19-14.59.log.html
Here's the ticket for this in the Fedora Cloud WG tracker: https://pagure.io/cloud-sig/issue/345
Note that using UEFI will break ability to use internal snapshots of VMs. This is the main reason why GNOME Boxes only uses UEFI in cases where the guest OS does not support legacy BIOS. We have done QEMU work needed to lift this limitation, but still need libvirt work done.
(In reply to Daniel Berrangé from comment #2) > Note that using UEFI will break ability to use internal snapshots of VMs. > This is the main reason why GNOME Boxes only uses UEFI in cases where the > guest OS does not support legacy BIOS. We have done QEMU work needed to lift > this limitation, but still need libvirt work done. Good to know! For what it's worth, this is the kind of info I hoped to get as part of filing these BZs. Obviously, we'd like functional parity before switching defaults.
*** Bug 1997884 has been marked as a duplicate of this bug. ***
To expand on my earlier comment and repeat what I've written in other places.... Using UEFI by default is fraught with edge cases. If an OS explicitly drops support for using UEFI then we can express this in libosinfo and do the right thing to use UEFI by default. This is needed since Windows 11 for example. This is the easy case. If an OS supports both BIOS/UEFI then it is much harder. If launching an installer to provision a new VM we could possibly run it in UEFI mode, *IF* we know it is run interactively. For a non-interactive install there's no reliable default. In Fedora case we're at the mercy of whatever the user wrote in their kickstart file as to whether its going to try to do a UEFI or BIOS install. If importing a pre-existing disk image (eg cloud image), then even if the OS vendor is building their official cloud images with dual UEFI/BIOS support we can't assume we have an official image. Users often build their own customized images and so we're again susceptible to whatever junk they put into their kickstart files. In both cases, using BIOS by default is the safer option, unless we've been told to turn on a feature that implies UEFI. eg if user asks for secureboot, then obviously we'll need UEFI. IOW, if Fedora explicitly drops BIOS support then UEFI is easy. As long as BIOS support exists, then defaulting to BIOS is generally better.
This bug has lingered for 2.5 years. I'm closing it, but I've filed an upstream virt-install issue to track some of the technical work we would need for this: https://github.com/virt-manager/virt-manager/issues/757 But I don't think this is a change virt-install/virt-manager should make in isolation. If someone wanted to make this happen for Fedora, might be interesting to file a Feature for it and open it up to broader discussion.