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