libvirt VS BootDuet

Only in trivial cases. The problem is when another part of the program holds a function pointer (eg callback) into the library which has been unloaded.

libvirt has long been linked with -Wl,nodelete to avoid this:

https://gitlab.com/libvirt/libvirt/-/commit/8e44e5593eb9b89f...

So, next I setup cockpit and cockpit-machines, which works to create VMs (via cockpit-machines) but they use tcg/qemu i.e. emulation and no KVM based h/w acceleration - my test VMs were very slow! I figured out while qemu+KVM works on command line, it doesn't work and the culprit was libvirt! After discussing with the good folks on #asahi channel and with tobhe (Ubuntu-Asahi creator), I gathered enough evidence to conclude libvirtd doesn't know the "right" qemu commands to exec and logged my findings to the libvirt project https://gitlab.com/libvirt/libvirt/-/issues/365 (which can probably use some of the community noise, to expedite the fix).

Nvidia 510 introduced a regression you can see the relevant issues here and here

The work to split into multiple daemons started a few years ago.

https://gitlab.com/libvirt/libvirt/-/blob/9b8bb536ff999fa61e...

There have been a few complaints online in the Arch and Gitlab forums regarding this issue. https://gitlab.com/libvirt/libvirt/-/issues/410

The issue stems from a change in libvirt. Libvirt is responsible for parsing all your VM's XML and turning it into a QEMU command. Somewhere between libvirt version 6.6 and version 6.9, there was a slight change in the way USB devices are passed to QEMU, and obviously libvirt followed suit. As a result, some USB passthrough configurations, such as the MacOS one in the thread, as well as the onboard bluetooth for windows suffered errors.

It's a bug, fix is upstream: https://gitlab.com/libvirt/libvirt/-/commit/04736179b283f55f62616a20a1ec95c665aab8ca

UEFI emulation is a thing.

For people with legacy-only firmware systems, you too can run UEFI on lazy cloud providers and legacy hardware. I do this on my 14 year old dell laptop just so that all my x86_64 systems have the same boot efistub linux kernel images. All you need is to use one of the EDK DUET bootloader builds such as BootDuet¹, or for an easier user experience CloverBootloader². Only complaint is secureboot emulation can be a pain. But I imagine with Windows 11 around the corner requiring TPMs, emulators with this feature will probably get more popular.

¹ https://github.com/migle/BootDuet