[Bug 1196087] New: libvirt on MicroOS on Raspberry Pi 4 requires additional packages to create a kvm virtual machine
http://bugzilla.opensuse.org/show_bug.cgi?id=1196087 Bug ID: 1196087 Summary: libvirt on MicroOS on Raspberry Pi 4 requires additional packages to create a kvm virtual machine Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs@opensuse.org Reporter: felix.niederwanger@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Created attachment 856256 --> http://bugzilla.opensuse.org/attachment.cgi?id=856256&action=edit Screenshot of virt-manager failing to connect to hypervisor Installing the libvirt package on MicroOS on a Raspberry Pi 4B does not install all necessary requirements to run a KVM machine. To be able to create a VM via virt-manager (from another machine) the following two packages are still required to be manually installed: * qemu-arm * qemu-ipxe Without the first package, virt-manager shows the error "No hypervisor options where found for this connection" (See attached Screenshot). In the journal on the MicroOS host I find the following error messages:
Feb 17 12:05:02 rabbit libvirtd[1328]: libvirt version: 8.0.0 Feb 17 12:05:02 rabbit libvirtd[1328]: hostname: rabbit Feb 17 12:05:02 rabbit libvirtd[1328]: Cannot check QEMU binary /usr/libexec/qemu-kvm: No such file or directory Feb 17 12:05:02 rabbit libvirtd[1328]: Cannot check QEMU binary /usr/libexec/qemu-kvm: No such file or directory
Here, libvirtd is running and active. Installing the `qemu-arm` solved this issue. The next issue is that starting a VM on this systems results in the following error message:
Unable to complete install: 'internal error: process exited while connecting to monitor: 2022-02-17T12:57:28.204430Z qemu-system-aarch64: -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:42:6b:15,bus=pci.1,addr=0x0: failed to find romfile "efi-virtio.rom"'
The file /usr/share/qemu/efi-virtio.rom is provided by `qemu-ipxe` and not present on the system by default. Installing this package resolved this issue and I was afterwards able to run a VM. All issues above state are only present on MicroOS (probably because it does not install recommended packages) on a Raspberry Pi and are not present on a fresh install using the current Tumbleweed image. Since `libvirt-daemon-driver-qemu` gets installed with libvirt, I wonder if it would not make sense to also make those packages as requirements? The current state of the libvirt package on MicroOS requires additional packages in order to run a simple kvm VM. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1196087 http://bugzilla.opensuse.org/show_bug.cgi?id=1196087#c1 --- Comment #1 from Dario Faggioli <dfaggioli@suse.com> --- (In reply to Felix Niederwanger from comment #0)
Since `libvirt-daemon-driver-qemu` gets installed with libvirt, I wonder if it would not make sense to also make those packages as requirements? The current state of the libvirt package on MicroOS requires additional packages in order to run a simple kvm VM.
So, this is related to, but also different than bug 1158430. There the problem was solved by adding the 'Requires:` for `qemu-arm` and `qemu-ipxe` in the KVM pattern. However, on MicroOS, you may not want to install the entire pattern. The fact that we also don't install recommended package is the other side of the issue. In fact, currently, the chain of dependencies is: - libvirt-daemon-driver-qemu requires qemu - qemu (on ARM) recommends qemu-arm The qemu package contains docs, some data, icons and other files, but no binaries. Just out of the top of my head, I don't see a sensible use case where someone wants to only have that package, and none of the ones that comes with the actual emulator binaries. That's to say that I'd be inclined to make the qemu package requiring the qemu-arm package (on ARM, of course; on other arches, we'd require the appropriate qemu-%{arch} package). And not just because it makes things better for MicroOS (and in general for everyone using --no-recommends), but because it seems to me that it just makes sense. What I don't know, however, is why the previous QEMU maintainers did things that way... And I guess I may be missing use-cases or scenarios where requiring those packages could be a problem. So, I will try harder to figure out if there could be any downside of such a change, and discuss that within the team. Should anyone have any idea --in either direction-- just add them here... -- You are receiving this mail because: You are the assignee for the bug.
participants (1)
-
bugzilla_noreply＠suse.com