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.
