Warning : Failed to set up UEFI / The Libvirt version does not support UEFI / Install options are limited...
Pavel Hrdina
phrdina at redhat.com
Tue Aug 22 16:05:45 UTC 2023
On Tue, Aug 22, 2023 at 05:55:30PM +0200, Mario Marietto wrote:
> I have installed virt-manager and all its dependencies grabbing the files
> from the devuan 5 repository.
> To recompile libvirt I need to acquire some basic information. Which
> version should I compile ? Where is the source code located ? Do you have
> some tutorial that explains the necessary steps to do it ? thanks.
Everything can be found at https://libvirt.org/ not sure which version
to pick, you can try latest upstream version but there might be some
dependencies missing in Devuan, if that happens you can fallback to
version that is provided by Devuan.
For example this link has basic info on how to compile libvirt
https://libvirt.org/compiling.html and here you can find sources
to libvirt https://libvirt.org/downloads.html .
Pavel
> On Tue, Aug 22, 2023 at 5:50 PM Pavel Hrdina <phrdina at redhat.com> wrote:
>
> > On Tue, Aug 22, 2023 at 05:28:50PM +0200, Mario Marietto wrote:
> > > root at devuan:~# virsh domcapabilities --machine virt --emulatorbin
> > > /usr/bin/qemu-system-arm
> > >
> > > error: failed to get emulator capabilities
> > > error: KVM is not supported on this platform: Function not implemented
> > >
> > > BUT it's not true :
> > >
> > > root at devuan:~# kvm-ok
> > >
> > > INFO: /dev/kvm exists
> > > KVM acceleration can be used
> >
> > Are you using libvirt installed using package manager or some libvirt
> > that you compiled yorself? Checking libvirt code this error only happens
> > if libvirt was compiled without KVM, more specifically if header
> > `/usr/include/linux/kvm.h` doesn't exists.
> >
> > I was not able to find any details on Devuan distro so not sure how
> > the libvirt package is compiled. You might need to try compiling libvirt
> > yourself.
> >
> > Pavel
> >
> > >
> > > On Tue, Aug 22, 2023 at 5:27 PM Mario Marietto <marietto2008 at gmail.com>
> > > wrote:
> > >
> > > > 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.
> > > >
> > >
> > >
> > > --
> > > Mario.
> >
>
>
> --
> Mario.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20230822/4cbcad45/attachment.sig>
More information about the virt-tools-list
mailing list