Nathan Vander Wilt
2021-Nov-26 23:08 UTC
virsh create fails with "Unable to find any firmware to satisfy 'efi'" for aarch64 guest on macOS
I am having trouble when I `virsh create test.xml` with an aarch64
guest on a macOS (Apple Silicon) host. I've wrestled with a variety of
issues but the one I simply haven't been able to get past is this
regarding the UEFI firmware:
error: Failed to create domain from test.xml
error: operation failed: Unable to find any firmware to satisfy 'efi'
This is with `virsh --version` of 7.9.0 and `qemu-system-aarch64
--version` of 6.1.0, both installed via the common `brew` tool from
its main 'homebrew/core' tap. I have confirmed that the loader/nvram
files referenced do exist.
Running `qemu-system-aarch64 -L help` outputs two lines:
/opt/homebrew/Cellar/qemu/6.1.0_1/bin/../share/qemu-firmware
/opt/homebrew/Cellar/qemu/6.1.0_1/bin/../share/qemu
The ?/share/qemu-firmware folder does NOT exist, but symlinking it to
a ?/share/qemu/firmware folder which does exist does not improve the
situation.
I have also tried renaming the ?/share/qemu/firmware folder (e.g. `mv
firmware zzz-firmware`) as some notes I found led me to believe that
libvirst might ignore my loader/nvram settings entirely if QEMU had
the "new" firmware JSON configuration stuff there? But again no
improvement?.
How can I debug this further? What should I try next?
thanks,
-natevw
--- the test.xml domain configuration I am trying ---
<domain type="qemu"
xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0">
<name>test1</name>
<uuid>D45FCA3E-B873-4608-A0B8-3D8529E7CFB7</uuid>
<memory unit="MiB">2048</memory>
<cpu mode="host-model" check="partial" />
<vcpu>2</vcpu>
<clock offset="utc"/>
<qemu:commandline>
<qemu:arg value='-accel'/>
<qemu:arg value='hvf'/>
</qemu:commandline>
<os firmware="efi">
<type arch="aarch64"
machine="virt">hvm</type>
<loader readonly="yes" secure="no"
type="pflash">/opt/homebrew/share/qemu/edk2-aarch64-code.fd</loader>
<nvram
template="/opt/homebrew/share/qemu/edk2-arm-vars.fd">/Users/me/vm_testing/vm-test1.efi.fd</nvram>
<bootmenu enable="no"/>
<boot dev="hd"/>
</os>
<features>
<acpi/>
<gic version="3"/>
<pae/>
</features>
<devices>
<emulator>/opt/homebrew/bin/qemu-system-aarch64</emulator>
<disk type="file" device="disk">
<driver name="qemu" type="qcow2"/>
<source file="/Users/me/vm_testing/vm-test1.qcow2"/>
<target dev="vda" bus="virtio"/>
</disk>
<interface type="network">
<source network="default"/>
<model type="virtio"/>
</interface>
<console type="pty">
<target type="serial" port="0"/>
</console>
<rng model="virtio">
<backend model="random">/dev/urandom</backend>
</rng>
</devices>
</domain>
Michal Prívozník
2021-Nov-27 07:08 UTC
virsh create fails with "Unable to find any firmware to satisfy 'efi'" for aarch64 guest on macOS
On 11/27/21 00:08, Nathan Vander Wilt wrote:> I am having trouble when I `virsh create test.xml` with an aarch64 > guest on a macOS (Apple Silicon) host. I've wrestled with a variety of > issues but the one I simply haven't been able to get past is this > regarding the UEFI firmware: > > error: Failed to create domain from test.xml > error: operation failed: Unable to find any firmware to satisfy 'efi' > < > This is with `virsh --version` of 7.9.0 and `qemu-system-aarch64 > --version` of 6.1.0, both installed via the common `brew` tool from > its main 'homebrew/core' tap. I have confirmed that the loader/nvram > files referenced do exist. > > Running `qemu-system-aarch64 -L help` outputs two lines: > > /opt/homebrew/Cellar/qemu/6.1.0_1/bin/../share/qemu-firmware > /opt/homebrew/Cellar/qemu/6.1.0_1/bin/../share/qemu > > The ?/share/qemu-firmware folder does NOT exist, but symlinking it to > a ?/share/qemu/firmware folder which does exist does not improve the > situation. > > I have also tried renaming the ?/share/qemu/firmware folder (e.g. `mv > firmware zzz-firmware`) as some notes I found led me to believe that > libvirst might ignore my loader/nvram settings entirely if QEMU had > the "new" firmware JSON configuration stuff there? But again no > improvement?. > > > How can I debug this further? What should I try next? > > thanks, > -natevw > > > --- the test.xml domain configuration I am trying --- > > <domain type="qemu" xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0"> > <name>test1</name> > <uuid>D45FCA3E-B873-4608-A0B8-3D8529E7CFB7</uuid> > <memory unit="MiB">2048</memory> > <cpu mode="host-model" check="partial" /> > <vcpu>2</vcpu> > <clock offset="utc"/> > <qemu:commandline> > <qemu:arg value='-accel'/> > <qemu:arg value='hvf'/> > </qemu:commandline> > <os firmware="efi">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. 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).> <type arch="aarch64" machine="virt">hvm</type> > <loader readonly="yes" secure="no" > type="pflash">/opt/homebrew/share/qemu/edk2-aarch64-code.fd</loader> > <nvram template="/opt/homebrew/share/qemu/edk2-arm-vars.fd">/Users/me/vm_testing/vm-test1.efi.fd</nvram> > <bootmenu enable="no"/> > <boot dev="hd"/> > </os> > <features> > <acpi/> > <gic version="3"/> > <pae/> > </features> > <devices> > <emulator>/opt/homebrew/bin/qemu-system-aarch64</emulator> > <disk type="file" device="disk"> > <driver name="qemu" type="qcow2"/> > <source file="/Users/me/vm_testing/vm-test1.qcow2"/> > <target dev="vda" bus="virtio"/> > </disk> > <interface type="network"> > <source network="default"/> > <model type="virtio"/> > </interface> > <console type="pty"> > <target type="serial" port="0"/> > </console> > <rng model="virtio"> > <backend model="random">/dev/urandom</backend> > </rng> > </devices> > </domain> > >Michal
Ján Tomko
2021-Nov-29 10:27 UTC
virsh create fails with "Unable to find any firmware to satisfy 'efi'" for aarch64 guest on macOS
On a Friday in 2021, Nathan Vander Wilt wrote:>I am having trouble when I `virsh create test.xml` with an aarch64 >guest on a macOS (Apple Silicon) host. I've wrestled with a variety of >issues but the one I simply haven't been able to get past is this >regarding the UEFI firmware: > >error: Failed to create domain from test.xml >error: operation failed: Unable to find any firmware to satisfy 'efi' > >This is with `virsh --version` of 7.9.0 and `qemu-system-aarch64 >--version` of 6.1.0, both installed via the common `brew` tool from >its main 'homebrew/core' tap. I have confirmed that the loader/nvram >files referenced do exist. > >Running `qemu-system-aarch64 -L help` outputs two lines: > >/opt/homebrew/Cellar/qemu/6.1.0_1/bin/../share/qemu-firmware >/opt/homebrew/Cellar/qemu/6.1.0_1/bin/../share/qemu > >The ?/share/qemu-firmware folder does NOT exist, but symlinking it to >a ?/share/qemu/firmware folder which does exist does not improve the >situation. > >I have also tried renaming the ?/share/qemu/firmware folder (e.g. `mv >firmware zzz-firmware`) as some notes I found led me to believe that >libvirst might ignore my loader/nvram settings entirely if QEMU had >the "new" firmware JSON configuration stuff there? But again no >improvement?. > > >How can I debug this further? What should I try next? > >thanks, >-natevwCan you try with the latest libvirt? 7.10.0-rc2 was just tagged today and should be out this week: https://listman.redhat.com/archives/libvirt-announce/2021-November/msg00002.html Andrea did some fixes that are supposed to help with Apple Silicon: https://gitlab.com/libvirt/libvirt/-/issues/168 Jano -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20211129/8f7f38ec/attachment.sig>