Warning : Failed to set up UEFI / The Libvirt version does not support UEFI / Install options are limited...

Mario Marietto marietto2008 at gmail.com
Tue Aug 22 15:27:01 UTC 2023


Oh sorry....

On Tue, Aug 22, 2023 at 5:26 PM Mario Marietto <marietto2008 at gmail.com>
wrote:

> virsh domcapabilities --machine virt --emulatorbin
> /path/to/qemu-system-arm
>
> error: failed to get emulator capabilities
> error: Cannot check QEMU binary /path/to/qemu-system-arm: No such file or
> directory
>
> On Tue, Aug 22, 2023 at 4:49 PM Pavel Hrdina <phrdina at redhat.com> wrote:
>
>> On Tue, Aug 22, 2023 at 04:05:09PM +0200, Mario Marietto wrote:
>> > Where does libvirt want to find those files ? since the qemu 5.1
>> > installation files have been placed under /usr/local during the command
>> > make install,I have also copied the firmware files in :
>> >
>> > ls /usr/local/share/AAVMF
>> >
>> > AAVMF32_CODE.fd  AAVMF_CODE.fd     AAVMF_CODE.snakeoil.fd
>> AAVMF_VARS.ms.fd
>> > AAVMF32_VARS.fd  AAVMF_CODE.ms.fd  AAVMF_VARS.fd
>> >           AAVMF_VARS.snakeoil.fd
>> >
>> > but they aren't still recognized.
>>
>> Downgrading libvirt would not help in this specific case. Since version
>> 5.2.0 libvirt uses firmware auto-selection. Libvirt is looking for json
>> files describing available firmwares. It is documented in QEMU project
>> git repository in `docs/interop/firmware.json`, this specific section
>> describes where the json files should be placed:
>>
>> # It is recommended to create firmware JSON files (each containing a
>> # single @Firmware root element) with a double-digit prefix, for example
>> # "50-ovmf.json", "50-seabios-256k.json", etc, so they can be sorted in
>> # predictable order. The firmware JSON files should be searched for in
>> # three directories:
>> #
>> #   - /usr/share/qemu/firmware -- populated by distro-provided firmware
>> #                                 packages (XDG_DATA_DIRS covers
>> #                                 /usr/share by default),
>> #
>> #   - /etc/qemu/firmware -- exclusively for sysadmins' local additions,
>> #
>> #   - $XDG_CONFIG_HOME/qemu/firmware -- exclusively for per-user local
>> #                                       additions (XDG_CONFIG_HOME
>> #                                       defaults to $HOME/.config).
>>
>> It doesn't matter where the *CODE* and *VARS* firmware files are placed
>> if the path to these files is correct in the json files in one of the
>> three directories.
>>
>> Looking at the qemu-efi-arm package it should install
>>
>>     /usr/share/AAVMF/AAVMF32_CODE.fd
>>     /usr/share/AAVMF/AAVMF32_VARS.fd
>>     /usr/share/qemu/firmware/60-edk2-arm.json
>>
>> and that should be picked up correctly by libvirt.
>>
>>
>> I don't know what machine types are available for 32bit ARM, but you
>> should be able to figure that out by running:
>>
>>     virsh capabilities | grep canonical
>>
>> it will show only lines with machine types, but my guess is on arm there
>> should be 'virt' machine type so running
>>
>>     virsh domcapabilities --machine virt --emulatorbin
>> /path/to/qemu-system-arm
>>
>> where you should be able to see the firmware paths if they are correctly
>> detected by libvirt.
>>
>> Pavel
>>
>>
>> > On Tue, Aug 22, 2023 at 3:55 PM Mario Marietto <marietto2008 at gmail.com>
>> > wrote:
>> >
>> > > I've already did that :
>> > >
>> > > # apt install qemu-efi-arm
>> > >
>> > > Reading package lists... Done
>> > > Building dependency tree... Done
>> > > Reading state information... Done
>> > > qemu-efi-arm is already the newest version (2022.11-6).
>> > > qemu-efi-arm set to manually installed.
>> > >
>> > > if I don't get wrong,that package do the installation of the following
>> > > files :
>> > >
>> > > root at devuan:/usr/share/AAVMF# ls
>> > >
>> > > AAVMF32_CODE.fd  AAVMF_CODE.fd     AAVMF_CODE.snakeoil.fd
>> > >  AAVMF_VARS.ms.fd
>> > > AAVMF32_VARS.fd  AAVMF_CODE.ms.fd  AAVMF_VARS.fd
>> > >           AAVMF_VARS.snakeoil.fd
>> > >
>> > > in my case they have been correctly placed under /usr/share/AAVMF
>> > >
>> > > I'm not sure that the problem is there. The error message talks about
>> the
>> > > libvirt version that could be wrong. What about if I retrocede libirt
>> 7.0
>> > > to 6.9 for example. Why 6.9 ?
>> > >
>> > >
>> > > As you can read below,it supports qemu 5.0 and newer...
>> > >
>> > > v6.9.0 (2020-11-02)
>> > >
>> > >    -
>> > >
>> > >    *New features*
>> > >    -
>> > >
>> > >       nodedev: Add support for channel subsystem (CSS) devices on S390
>> > >
>> > >       A CSS device is represented as a parent device of a CCW device.
>> > >       This support allows to create vfio-ccw mediated devices with
>> > >       virNodeDeviceCreateXML().
>> > >       -
>> > >
>> > >       qemu: Implement memory failure event
>> > >
>> > >       New event is implemented that is emitted whenever a guest
>> > >       encounters a memory failure.
>> > >       -
>> > >
>> > >       qemu: Implement support for <transient/> disks
>> > >
>> > >       VMs based on the QEMU hypervisor now can use <transient/> option
>> > >       for local file-backed disks to configure a disk which discards
>> changes made
>> > >       to it while the VM was active.
>> > >       -
>> > >
>> > >       hyperv: implement new APIs
>> > >
>> > >       The virConnectGetCapabilities(), virConnectGetMaxVcpus(),
>> > >       virConnectGetVersion(), virDomainGetAutostart(),
>> > >       virDomainSetAutostart(), virNodeGetFreeMemory(),
>> virDomainReboot(),
>> > >       virDomainReset(), virDomainShutdown(), and
>> virDomainShutdownFlags()
>> > >       APIs have been implemented in the Hyper-V driver.
>> > >       -
>> > >
>> > >       bhyve: implement virtio-9p filesystem support
>> > >
>> > >       Implement virito-9p shared filesystem using the <filesystem/>
>> > >       element.
>> > >       -
>> > >
>> > >       qemu: Add support for vDPA network devices.
>> > >
>> > >       VMs using the QEMU hypervisor can now specify vDPA network
>> devices
>> > >       using <interface type='vdpa'>. The node device APIs also now
>> list
>> > >       and provide XML descriptions for vDPA devices.
>> > >       -
>> > >
>> > >       cpu_map: Add EPYC-Rome CPU model
>> > >
>> > >       *It's supported in QEMU 5.0.0 and newer.*
>> > >       -
>> > >
>> > >       cpu: Add a flag for XML validation in CPU comparison
>> > >
>> > >       The virConnectCompareCPU and virConnectCompareHypervisorCPU API
>> now
>> > >       support the VIR_CONNECT_COMPARE_CPU_VALIDATE_XML flag, which
>> > >       enables XML validation. For virsh, this feature is enabled by
>> passing the
>> > >       --validate option to the cpu-compare and hypervisor-cpu-compare
>> > >       subcommands.
>> > >       -
>> > >
>> > >       qemu: Introduce virtio-balloon free page reporting feature
>> > >
>> > >       Introduce the optional attribute free-page-reporting for virtio
>> > >       memballoon device. It enables/disables the ability of the QEMU
>> virtio
>> > >       memory balloon to return unused pages back to the hypervisor.
>> QEMU 5.1 and
>> > >       newer support this feature.
>> > >       -
>> > >
>> > >    *Improvements*
>> > >    -
>> > >
>> > >       qemu: Make 'cbitpos' & 'reducedPhysBits' attrs optional
>> > >
>> > >       Libvirt probes the underlying platform in order to fill in these
>> > >       SEV attributes automatically before launching a guest.
>> > >       -
>> > >
>> > >       util: support device stats collection for SR-IOV VF hostdev
>> > >
>> > >       For SR-IOV VF hostdevs, libvirt now supports retrieving device
>> > >       traffic stats via the virDomainInterfaceStats API and virsh
>> > >       domifstat.
>> > >       -
>> > >
>> > >       logging: Allow disabling log rollover
>> > >
>> > >       Set max_len=0 in virtlogd.conf to disable log rollover.
>> > >       -
>> > >
>> > >       qemu: Set noqueue qdisc for TAP devices
>> > >
>> > >       Set noqueue instead of the former pfifo_fast queue discipline
>> for
>> > >       TAP devices. It will avoid needless cost of host CPU cycles and
>> thus
>> > >       improve performance.
>> > >       -
>> > >
>> > >       qemu: virtiofs can be used without NUMA nodes
>> > >
>> > >       Virtiofs is supported for the VM without NUMA nodes but
>> configured
>> > >       with shared memory.
>> > >       -
>> > >
>> > >    *Bug fixes*
>> > >    -
>> > >
>> > >       hyperv: ensure WQL queries work in all locales
>> > >
>> > >       Relying on the "Description" field caused queries to fail on
>> > >       non-"en-US" systems. The queries have been updated to avoid
>> using localized
>> > >       strings.
>> > >       -
>> > >
>> > >       rpc: Fix virt-ssh-helper detection
>> > >
>> > >       libvirt 6.8.0 failed to correctly detect the availability of the
>> > >       new virt-ssh-helper command on the remote host, and thus always
>> > >       used the fallback instead; this has now been fixed.
>> > >
>> > >
>> > > What do you think ? Can you share some documentation about how to
>> > > recompile an older version of libvirt from source code ? thanks.
>> > >
>> > > On Tue, Aug 22, 2023 at 3:35 PM Pavel Hrdina <phrdina at redhat.com>
>> wrote:
>> > >
>> > >> On Tue, Aug 22, 2023 at 02:49:05PM +0200, Mario Marietto wrote:
>> > >> > Hello to everyone.
>> > >> >
>> > >> > I'm trying to use qemu 5.1 with virt-manager and libvirt on my ARM
>> > >> > chromebook (armhf 32 bit cpu) running with Devuan 4 as host o.s.
>> > >> >
>> > >> > By default it uses qemu and its dependencies,version 5.2. I
>> remember
>> > >> that I
>> > >> > can't use qemu 5.2,because it doesn't have any support for KVM as
>> you
>> > >> can
>> > >> > read here :
>> > >> >
>> > >> >
>> > >> >
>> https://lists.gnu.org/archive/html/qemu-devel/2020-09/msg02074.html
>> > >> >
>> > >> >
>> > >> > For this reason,I've compiled qemu 5.1 from source. Below I shown
>> how I
>> > >> > have configured everything such as a little piece of compilation
>> > >> messages :
>> > >> >
>> > >> >
>> > >> > # apt install libgtk-3-dev libpulse-dev libgbm-dev
>> libspice-protocol-dev
>> > >> > libspice-server-dev libusb-1.0-0-dev libepoxy-dev
>> > >> >
>> > >> >
>> > >> > # cp /root/Desktop/qemu-v5.1.0/arm-softmmu/qemu-system-arm /usr/bin
>> > >> >
>> > >> > # CFLAGS=-Wno-error ./configure --target-list=x86_64-softmmu
>> > >> --enable-opengl
>> > >> > --enable-gtk --enable-kvm --enable-guest-agent --enable-spice
>> > >> --audio-drv-
>> > >> > list="oss pa" --enable-libusb
>> > >> >
>> > >> >
>> > >> > A little piece of the log messages that I've got from the
>> compilation of
>> > >> > qemu 5.1 :
>> > >> >
>> > >> >
>> > >> > https://pastebin.ubuntu.com/p/8DYfgPvhXy/
>> > >> >
>> > >> >
>> > >> > These are the resulting versions of my frankenstein operation :
>> > >> >
>> > >> >
>> > >> > # virsh version
>> > >> >
>> > >> > Compiled against library: libvirt 7.0.0
>> > >> > Using library: libvirt 7.0.0
>> > >> > Using API: QEMU 7.0.0
>> > >> > Running hypervisor: QEMU 5.1.0
>> > >> >
>> > >> >
>> > >> > At this point I ran virt-manager. It has been able to detect
>> qemu,but I
>> > >> get
>> > >> > the following error :
>> > >> >
>> > >> >
>> > >> > Warning : Failed to set up UEFI.
>> > >> > The Libvirt version does not support UEFI.
>> > >> > Install options are limited.
>> > >> >
>> > >> > (I have also tried upgrading devuan 4 with devuan 5 and I've got
>> the
>> > >> same
>> > >> > error :
>> > >>
>> > >> You most likely need to install qemu-efi-arm package which should
>> > >> provide 32bit arm firmware files. The package name is a bit confusing
>> > >> as it doesn't originate from qemu project, it is from edk2 project.
>> > >>
>> > >> Without this package libvirt most likely doesn't report any efi files
>> > >> and that's what causes the error you are hitting.
>> > >>
>> > >> Pavel
>> > >>
>> > >> >
>> > >> >
>> > >> > root at devuan:/usr/bin# virsh version
>> > >> >
>> > >> > Compiled against library: libvirt 9.0.0
>> > >> > Using library: libvirt 9.0.0
>> > >> > Using API: QEMU 9.0.0
>> > >> > Running hypervisor: QEMU 5.1.0
>> > >> >
>> > >> >
>> > >> > If I change qemu-system-arm vers. 5.1 with qemu-system-arm 5.2,the
>> error
>> > >> > disappears. So,it seems that libvirt does not accept
>> qemu-system-arm
>> > >> vers.
>> > >> > 5.1 or maybe any version lower than 5.2,I don't know. But as I've
>> said,I
>> > >> > can't use any version of qemu greater or equal to 5.2 on my setup.
>> And I
>> > >> > want to use virt-manager and libvirt because I find these tools
>> very
>> > >> > comfortable instead of using the "raw" qemu parameters. Is there a
>> > >> > workaround ? Maybe I can recompile virt-manager and / or libvirt
>> from
>> > >> the
>> > >> > source code ? but how ? Do you think that it could work if I use
>> > >> something
>> > >> > like this (if it exists and if it can be reached in some way) :
>> > >> >
>> > >> >
>> > >> > Compiled against library: libvirt 5.0.0
>> > >> > Using library: libvirt 5.0.0
>> > >> > Using API: QEMU 5.0.0
>> > >> > Running hypervisor: QEMU 5.1.0
>> > >> >
>> > >> >
>> > >> > thanks.
>> > >> >
>> > >> > --
>> > >> > Mario.
>> > >>
>> > >
>> > >
>> > > --
>> > > Mario.
>> > >
>> >
>> >
>> > --
>> > Mario.
>>
>
>
> --
> Mario.
>


-- 
Mario.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20230822/253e50ff/attachment.htm>


More information about the virt-tools-list mailing list