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 16:22:25 UTC 2023


In your opinion should I remove virt-manager and all its dependencies
before launching the recompilation ?

On Tue, Aug 22, 2023 at 6:05 PM Pavel Hrdina <phrdina at redhat.com> wrote:

> 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.
>


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


More information about the virt-tools-list mailing list