On Tue, Aug 22, 2023 at 05:28:50PM +0200, Mario Marietto wrote: > root@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@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@xxxxxxxxx> > wrote: > > > Oh sorry.... > > > > On Tue, Aug 22, 2023 at 5:26 PM Mario Marietto <marietto2008@xxxxxxxxx> > > 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@xxxxxxxxxx> 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@xxxxxxxxx > >>> > > >>> > 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@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@xxxxxxxxxx> > >>> 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@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.
Attachment:
signature.asc
Description: PGP signature
