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