virsh create fails with "Unable to find any firmware to satisfy 'efi'" for aarch64 guest on macOS

Nathan Vander Wilt nate-lists at calftrail.com
Tue Nov 30 05:33:34 UTC 2021


On Fri, Nov 26, 2021 at 11:08 PM Michal Prívozník <mprivozn at redhat.com> wrote:
> Since you are providing the path to both UEFI image and varstore you can
> drop this 'firmware="efi"' attribute. It's what's causing troubles here.

Thank you, yes!

> A short trip into not so distant past. UEFI was introduced to QEMU, so
> libvirt came up with <loader type="pflash>/path/to/uefi</loader> and
> <nvram/> combo. This was suboptimal, because now users had to guess
> which FW to select (because it depends on guest arch, secure boot
> enabled, SMM mode, ...). So QEMU started shipping small, machine
> readable files to each BIOS/UEFI image, which libvirt would parse and
> pick the best one for given domain XML. And this is what firmware='efi'
> controls. IOW, using firmware='efi' is incompatible with specifying
> paths in <loader/> and <nvram/> and if you define this XML you'd see
> that the paths are not formatted back (e.g. in virsh dumpxml).

Okay, yes this was unclear. It's not in the documentation afaict and I
saw some threads making it sound like it was the mere presence of the
JSON config files that made libvirt ignore any loader/nvram
configuration. But dropping the firmware attribute on the os element
was indeed the trick to get rid of the EFI error. Thanks for the
clarification!

regards,
-natevw





More information about the libvirt-users mailing list