Hello, Pavel,are you there ? Please help me to give it the last push. I've fixed the last error like so :
root@devuan:~/Desktop/libvirt/build# update-alternatives --set iptables /usr/sbin/iptables-legacy update-alternatives: using /usr/sbin/iptables-legacy to provide /usr/sbin/iptables (iptables) in manual mode but now I have got another error. Anyway,I feel to be close : root@devuan:~/Desktop/libvirt/build# sudo ./run src/virtlockd & sudo ./run src/virtlogd & sudo ./run src/libvirtd 2023-08-22 19:38:49.036+0000: 15002: info : libvirt version: 9.7.0 hostname: devuan error : virPidFileAcquirePathFull:409 : Failed to acquire pid file '/root/libvirt_build/var/run/virtlockd.pid': Resource temporarily unavailable On Tue, Aug 22, 2023 at 7:01 PM Mario Marietto <marietto2...@gmail.com> wrote: > Et voila'. I've recompiled libvirt in this way : > > git clone https://github.com/libvirt/libvirt.git > mkdir -p libvirt_build > cd libvirt > apt install meson xsltproc libgnutls28-dev libxml2-dev rst2pdf > meson build --prefix=$HOME/libvirt_build > ninja -C build > sudo ninja -C build install > cd build > nano vai.sh : > > sudo ./run src/virtlockd & sudo ./run src/virtlogd & sudo ./run > src/libvirtd > > chmod +x vai.sh > > this is the error I get : > > root@devuan:~/Desktop/libvirt/build# ./vai.sh > > 2023-08-22 16:52:34.416+0000: 14725: info : libvirt version: 9.7.0 > 2023-08-22 16:52:34.416+0000: 14725: info : hostname: devuan > 2023-08-22 16:52:34.416+0000: 14725: error : > virFirewallApplyRuleDirect:518 : internal error: Failed to apply > firewall rules /usr/sbin/iptables -w --table filter --list-rules: > iptables: Failed to initialize nft: Protocol not supported > > 2023-08-22 16:52:34.428+0000: 14725: error : > virFirewallApplyRuleDirect:518 : internal error: Failed to apply firewall > rules /usr/sbin/ip6tables -w --table filter --list-rules: ip6tables: Failed > to initialize nft: Protocol not supported > > On Tue, Aug 22, 2023 at 6:49 PM Pavel Hrdina <phrd...@redhat.com> wrote: > >> On Tue, Aug 22, 2023 at 06:22:25PM +0200, Mario Marietto wrote: >> > In your opinion should I remove virt-manager and all its dependencies >> > before launching the recompilation ? >> >> I would say there is no need to do that if you install libvirt to >> /usr/local as it should be separated from the libvirt installed by >> package manager. >> >> Pavel >> >> > >> > On Tue, Aug 22, 2023 at 6:05 PM Pavel Hrdina <phrd...@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 <phrd...@redhat.com> >> wrote: >> > > > >> > > > > 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 < >> > > marietto2...@gmail.com> >> > > > > > wrote: >> > > > > > >> > > > > > > Oh sorry.... >> > > > > > > >> > > > > > > On Tue, Aug 22, 2023 at 5:26 PM Mario Marietto < >> > > marietto2...@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 < >> phrd...@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 < >> > > > > marietto2...@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@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 < >> > > phrd...@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@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. >> > > > -- > Mario. > -- Mario.
