Bugzilla – Bug 1212352
Installation of TW: the convenience packages miss a dependency (no libvirt-daemon-driver-lxc)
Last modified: 2023-06-18 09:30:29 UTC
localhost:~ # systemctl status libvirtd > ○ libvirtd.service - Virtualization daemon > Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; > preset: disabled) > Active: inactive (dead) since Tue 2023-06-13 16:39:51 CEST; 6min ago > Duration: 34.794s > TriggeredBy: ● libvirtd.socket > ● libvirtd-admin.socket > ● libvirtd-ro.socket > Docs: man:libvirtd(8) > https://libvirt.org > Process: 27017 ExecStart=/usr/sbin/libvirtd $LIBVIRTD_ARGS (code=exited, > status=0/SUCCESS) > Main PID: 27017 (code=exited, status=0/SUCCESS) > CPU: 193ms > > Jun 13 16:39:16 localhost systemd[1]: Starting Virtualization daemon... > Jun 13 16:39:17 localhost systemd[1]: Started Virtualization daemon. > Jun 13 16:39:17 localhost libvirtd[27017]: libvirt version: 9.4.0 > Jun 13 16:39:17 localhost libvirtd[27017]: hostname: localhost > Jun 13 16:39:17 localhost libvirtd[27017]: internal error: template '/etc/ > apparmor.d/libvirt/TEMPLATE.lxc' does not exist > Jun 13 16:39:17 localhost libvirtd[27017]: no connection driver available > for lxc:/// > Jun 13 16:39:17 localhost libvirtd[27017]: End of file while reading data: > Errore di input/output > Jun 13 16:39:51 localhost systemd[1]: Stopping Virtualization daemon... > Jun 13 16:39:51 localhost systemd[1]: libvirtd.service: Deactivated > successfully. > Jun 13 16:39:51 localhost systemd[1]: Stopped Virtualization daemon. Found out the internet is quite stuffed with: no connection starting, leading to the solution that libvirt-daemon-driver-lxc - Plugin driver LXC per il demone libvirtd package is missing as dependency when installing the packages for KVM libvirt. Shouldn't this package be part of the convenience package? Maybe this could be related to a bug 859041 reported fixed in 2014 (regression)?
(In reply to Stakanov Schufter from comment #0) > > Jun 13 16:39:17 localhost libvirtd[27017]: internal error: template '/etc/ > > apparmor.d/libvirt/TEMPLATE.lxc' does not exist This is fixed by https://build.opensuse.org/request/show/1093000 > > Jun 13 16:39:17 localhost libvirtd[27017]: no connection driver available > > for lxc:/// This is interesting. How did you install libvirt? Did you use a pattern such as kvm_tools? > > Jun 13 16:39:17 localhost libvirtd[27017]: End of file while reading data: > > Errore di input/output > > Jun 13 16:39:51 localhost systemd[1]: Stopping Virtualization daemon... > > Jun 13 16:39:51 localhost systemd[1]: libvirtd.service: Deactivated > > successfully. > > Jun 13 16:39:51 localhost systemd[1]: Stopped Virtualization daemon. > > Found out the internet is quite stuffed with: no connection starting, > leading to the solution that > > libvirt-daemon-driver-lxc - Plugin driver LXC per il demone libvirtd > package is missing as dependency when installing the packages for KVM > libvirt. The lxc related packages shouldn't be needed for a KVM host.
I used the so called convenience packages from the repos. The thing is particular, because the kvm is on /var/lib/libvirt, so it "survived" the new install, and this is intentional, it is on a raid and it is meant to protect the images that I have historically. I am using a bridged setup with the ethernet card comprised within the br0 (so the br0 takes the dhcp and the eth is set not to take ip. When I do not install the lcx, all is ok, apparently but the connection does not start. When I do install that lcx library, then it does work perfectly. As soon as I rebooted after its install, I found the connect working. Now embarrassingly I do not even know...why one uses this lcx library (driver), but by searching on the internet I found several threads that say "requires it" to have the connect working. If you guide me through the commands to reveal eventual problems or bad settings, I am taker and willing to execute the commands you may require. (Not dd if=/dev/urandom of of course ;-) ).
(In reply to Stakanov Schufter from comment #2) > I used the so called convenience packages from the repos. What "convenience packages"? Please be more explicit and provide the package names. > The thing is particular, because the kvm is on /var/lib/libvirt, so it > "survived" the new install, and this is intentional, it is on a raid and it > is meant to protect the images that I have historically. > I am using a bridged setup with the ethernet card comprised within the br0 > (so the br0 takes the dhcp and the eth is set not to take ip. > > When I do not install the lcx, all is ok, apparently but the connection does > not start. When I do install that lcx library, then it does work perfectly. > As soon as I rebooted after its install, I found the connect working. I have several Tumbleweed KVM hosts that all work fine, and none of them have any lxc packages installed. > > Now embarrassingly I do not even know...why one uses this lcx library > (driver), but by searching on the internet I found several threads that say > "requires it" to have the connect working. The libvirt lxc driver is used to manage system containers, which is a separate and different thing than KVM. > If you guide me through the commands to reveal eventual problems or bad > settings, I am taker and willing to execute the commands you may require. Let's start by trying to figure out what you have installed and how it got installed. Along with the answer to my above question, can you please provide the libvirt rpms installed, e.g. 'rpm -qa | grep ^libvirt'?
First part of your question: localhost:~ # rpm -qa | grep ^libvirt libvirt-daemon-9.4.0-2.1.x86_64 libvirt-libs-9.4.0-2.1.x86_64 libvirt-glib-1_0-0-4.0.0-1.10.x86_64 libvirt-daemon-proxy-9.4.0-2.1.x86_64 libvirt-daemon-plugin-lockd-9.4.0-2.1.x86_64 libvirt-daemon-log-9.4.0-2.1.x86_64 libvirt-daemon-lock-9.4.0-2.1.x86_64 libvirt-client-9.4.0-2.1.x86_64 libvirt-daemon-common-9.4.0-2.1.x86_64 libvirt-daemon-driver-storage-core-9.4.0-2.1.x86_64 libvirt-daemon-driver-secret-9.4.0-2.1.x86_64 libvirt-daemon-driver-qemu-9.4.0-2.1.x86_64 libvirt-daemon-driver-nwfilter-9.4.0-2.1.x86_64 libvirt-daemon-driver-nodedev-9.4.0-2.1.x86_64 libvirt-daemon-driver-network-9.4.0-2.1.x86_64 libvirt-daemon-driver-interface-9.4.0-2.1.x86_64 libvirt-daemon-driver-storage-scsi-9.4.0-2.1.x86_64 libvirt-daemon-driver-storage-rbd-9.4.0-2.1.x86_64 libvirt-daemon-driver-storage-mpath-9.4.0-2.1.x86_64 libvirt-daemon-driver-storage-logical-9.4.0-2.1.x86_64 libvirt-daemon-driver-storage-iscsi-direct-9.4.0-2.1.x86_64 libvirt-daemon-driver-storage-iscsi-9.4.0-2.1.x86_64 libvirt-daemon-driver-storage-disk-9.4.0-2.1.x86_64 libvirt-daemon-config-network-9.4.0-2.1.x86_64 libvirt-daemon-driver-storage-9.4.0-2.1.x86_64 libvirt-daemon-qemu-9.4.0-2.1.x86_64 libvirt-daemon-driver-lxc-9.4.0-2.1.x86_64 libvirt-daemon-config-nwfilter-9.4.0-2.1.x86_64 libvirt-daemon-hooks-9.4.0-2.1.x86_64 libvirt-client-qemu-9.4.0-2.1.x86_64 libvirt-daemon-driver-libxl-9.4.0-2.1.x86_64 libvirt-9.4.0-2.1.x86_64 libvirt-dbus-1.4.1-3.5.x86_64 Then (sorry for calling them like this, but this is how they are called in the repos): "convenience packages": os-autoinst-qemu-kvm - Convenience package providing os-autoinst+qemu-kvm os-autoinst-qemu-x86 - Convenience package providing os-autoinst+qemu-x86 were the second was installed when after the first and reboot the connection still did not want to start. Thank you for the lighting fast answer BTW.
(In reply to Stakanov Schufter from comment #4) > First part of your question: > localhost:~ # rpm -qa | grep ^libvirt > libvirt-daemon-9.4.0-2.1.x86_64 > libvirt-libs-9.4.0-2.1.x86_64 > libvirt-glib-1_0-0-4.0.0-1.10.x86_64 > libvirt-daemon-proxy-9.4.0-2.1.x86_64 > libvirt-daemon-plugin-lockd-9.4.0-2.1.x86_64 > libvirt-daemon-log-9.4.0-2.1.x86_64 > libvirt-daemon-lock-9.4.0-2.1.x86_64 > libvirt-client-9.4.0-2.1.x86_64 > libvirt-daemon-common-9.4.0-2.1.x86_64 > libvirt-daemon-driver-storage-core-9.4.0-2.1.x86_64 > libvirt-daemon-driver-secret-9.4.0-2.1.x86_64 > libvirt-daemon-driver-qemu-9.4.0-2.1.x86_64 > libvirt-daemon-driver-nwfilter-9.4.0-2.1.x86_64 > libvirt-daemon-driver-nodedev-9.4.0-2.1.x86_64 > libvirt-daemon-driver-network-9.4.0-2.1.x86_64 > libvirt-daemon-driver-interface-9.4.0-2.1.x86_64 > libvirt-daemon-driver-storage-scsi-9.4.0-2.1.x86_64 > libvirt-daemon-driver-storage-rbd-9.4.0-2.1.x86_64 > libvirt-daemon-driver-storage-mpath-9.4.0-2.1.x86_64 > libvirt-daemon-driver-storage-logical-9.4.0-2.1.x86_64 > libvirt-daemon-driver-storage-iscsi-direct-9.4.0-2.1.x86_64 > libvirt-daemon-driver-storage-iscsi-9.4.0-2.1.x86_64 > libvirt-daemon-driver-storage-disk-9.4.0-2.1.x86_64 > libvirt-daemon-config-network-9.4.0-2.1.x86_64 > libvirt-daemon-driver-storage-9.4.0-2.1.x86_64 > libvirt-daemon-qemu-9.4.0-2.1.x86_64 > libvirt-daemon-driver-lxc-9.4.0-2.1.x86_64 > libvirt-daemon-config-nwfilter-9.4.0-2.1.x86_64 > libvirt-daemon-hooks-9.4.0-2.1.x86_64 > libvirt-client-qemu-9.4.0-2.1.x86_64 > libvirt-daemon-driver-libxl-9.4.0-2.1.x86_64 > libvirt-9.4.0-2.1.x86_64 > libvirt-dbus-1.4.1-3.5.x86_64 Looks like you have a lot of unneeded stuff if you're only interested in kvm. You should be able to safely 'rpm -e libvirt-9.4.0-2.1.x86_64 libvirt-daemon-driver-libxl-9.4.0-2.1.x86_64 libvirt-daemon-driver-lxc-9.4.0-2.1.x86_64'. The libvirt package is a "convenience package" itself, since it doesn't have any files, only dependencies on everything else. > Then (sorry for calling them like this, but this is how they are called in > the repos): > "convenience packages": > > os-autoinst-qemu-kvm - Convenience package providing os-autoinst+qemu-kvm > > os-autoinst-qemu-x86 - Convenience package providing os-autoinst+qemu-x86 Heh, learn something new every day. I never knew those existed. They too contain no files, but they don't require or recommends any libvirt packages, so I'm confused about how libvirt got installed on your system. # rpm -qlp os-autoinst-qemu-x86-4.6.1683886197.05274f7-1.2.x86_64.rpm (contains no files) # rpm -qp os-autoinst-qemu-x86-4.6.1683886197.05274f7-1.2.x86_64.rpm --requires e2fsprogs os-autoinst qemu-tools qemu-x86 >= 4.0.0 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 # rpm -qp os-autoinst-qemu-x86-4.6.1683886197.05274f7-1.2.x86_64.rpm --recommends # # rpm -qlp os-autoinst-qemu-kvm-4.6.1683886197.05274f7-1.2.x86_64.rpm (contains no files) # rpm -qp os-autoinst-qemu-kvm-4.6.1683886197.05274f7-1.2.x86_64.rpm --requires e2fsprogs os-autoinst qemu-kvm >= 4.0.0 qemu-tools rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 # rpm -qp os-autoinst-qemu-kvm-4.6.1683886197.05274f7-1.2.x86_64.rpm --recommends # Did you happen to manually install libvirt? E.g. 'zypper install libvirt'?
It is without any doubt possible that I did install libvirt manually. I think this arises out of confusion that libvirt is needed for virtualization with kvm/qemu. I have to admit that the relationship of kvm/qemu libvirt/virsh is for me a bit cryptic. For what I did understand (which is probably wrong) you need libvirt for kvm but now you tell me you don't.... Easy: what I want is a virtualization of several OS (Linux and non) running on my host. Now... I thought if I select kvm and the "convenience packages" (that I understood should have drawn necessary files) that should have done. Then I did run into that error. Well, I will now try to uninstall the non necessary stuff you mentioned and we will see if all works still well. Of course I am happy to take off all not strictly needed packages. Is it possible that I need libvirt because of the format of my virtual machines? They are all qcow2.
(In reply to Stakanov Schufter from comment #6) > It is without any doubt possible that I did install libvirt manually. When installing manually you need to better understand the purpose of the various packages. Upstream and SUSE has docs on the topic https://libvirt.org/kbase/rpm-deployment.html https://doc.opensuse.org/documentation/leap/virtualization/html/book-virtualization/cha-libvirt-overview.html > I think this arises out of confusion that libvirt is needed for > virtualization with kvm/qemu. > I have to admit that the relationship of kvm/qemu libvirt/virsh is for me a > bit cryptic. libvirt is a collection of services and tools for managing various hypervisors. It supports KVM/qemu, Xen, LXC, VirtualBox, ESX, and others. The most widely used are KVM and Xen. If you want a KVM/qemu host, install libvirt-daemon-qemu. For a Xen host, install libvirt-daemon-xen. For all you ever wanted to know about libvirt, visit https://libvirt.org :-). > For what I did understand (which is probably wrong) you need libvirt for kvm > but now you tell me you don't.... You can use qemu directly. See the qemu man page. But managing your VMs using the qemu command line and the qemu monitor can get unwieldly quickly. libvirt attempts to make it a bit easier, and provides a standard interface across hypervisors. Also, tools like virt-manager and virsh are based on libvirt. > Easy: what I want is a virtualization of several OS (Linux and non) running > on my host. > Now... I thought if I select kvm and the "convenience packages" (that I > understood should have drawn necessary files) that should have done. Then I > did run into that error. Well, I will now try to uninstall the non necessary > stuff you mentioned and we will see if all works still well. Of course I am > happy to take off all not strictly needed packages. Maybe it is clearer after reading the above docs. > Is it possible that I need libvirt because of the format of my virtual > machines? They are all qcow2. No. You likely need libvirt for ease of management. E.g. you want to use virt-manager vs the qemu command line. Do things work fine for you after removing the suggested packages?
Sorry for the late reply, I have some odd problems on that machine, had to change the mainboard and did the error to buy ASRock (second time in 20 years and reliably quite a failure for what is compatibility. Still, the two libs could be removed, but the rest is all dependency. Yes it works now, I could now open a bug because the lates version of Windows11 cannot be virtualized, but to tell the truth, it was just for the sake of trying the (unwanted) copy of it that came with the laptop.... So connection is up, TW and other distribution run well virtualized. Thank you for your help (more clear packages regulating the needed dependencies during first install of TW is however a suggestion that I have. Still that is OT and not part of this report that can be closed.