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:28:50 UTC 2023
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20230822/37f1dec0/attachment.htm>
More information about the virt-tools-list
mailing list