Bug 2016601
| Summary: | libvirtd.service does not start on Fedora 35 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | bengt |
| Component: | cockpit-machines | Assignee: | Katerina Koukiou <k.koukiou> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 35 | CC: | berrange, k.koukiou, mmarusak, mpitt |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-10-25 20:24:03 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1980027 | ||
|
Description
bengt
2021-10-22 08:16:45 UTC
I am starting from a Fedora 35 cloud image with `rpm -qa|grep libvirt` being empty. `dnf install cockpit-machines` pulls in 301 packages, amongst them these libvirt packages: libvirt-client libvirt-daemon libvirt-daemon-driver-interface libvirt-daemon-driver-network libvirt-daemon-driver-nodedev libvirt-daemon-driver-nwfilter libvirt-daemon-driver-qemu libvirt-daemon-driver-secret libvirt-daemon-driver-storage libvirt-daemon-driver-storage-core libvirt-daemon-driver-storage-disk libvirt-daemon-driver-storage-gluster libvirt-daemon-driver-storage-iscsi libvirt-daemon-driver-storage-iscsi-direct libvirt-daemon-driver-storage-logical libvirt-daemon-driver-storage-mpath libvirt-daemon-driver-storage-rbd libvirt-daemon-driver-storage-scsi libvirt-daemon-driver-storage-sheepdog libvirt-daemon-driver-storage-zfs libvirt-daemon-kvm libvirt-dbus libvirt-glib libvirt-libs After that, cockpit-machines indeed shows the "Virtualization service (libvirt) is not active" message, and the CLI fails as well: # virsh list error: failed to connect to the hypervisor error: Failed to connect socket to '/var/run/libvirt/virtqemud-sock': Connection refused # systemctl list-units --no-legend 'virt*' virtlockd.socket loaded active listening Virtual machine lock manager socket virtlogd.socket loaded active listening Virtual machine log manager socket virtnetworkd.socket loaded active listening Libvirt network local socket It works better as user, `virsh list` succeeds, and it starts virtqemud (and a few others). However, when I click the "Start" button in c-machines, I get the main view, and `systemctl status libvirtd` shows that it is running. That doesn't work for you, and that seems to correspond to your "If you go to command line you can not start libvirtd manual.". What does "systemctl show libvirtd libvirtd.socket" say for you after trying to start it? (In reply to Martin Pitt from comment #1) > I am starting from a Fedora 35 cloud image with `rpm -qa|grep libvirt` being > empty. `dnf install cockpit-machines` pulls in 301 packages, amongst them > these libvirt packages: snip > After that, cockpit-machines indeed shows the "Virtualization service > (libvirt) is not active" message, and the CLI fails as well: > > # virsh list > error: failed to connect to the hypervisor > error: Failed to connect socket to '/var/run/libvirt/virtqemud-sock': > Connection refused > > # systemctl list-units --no-legend 'virt*' > virtlockd.socket loaded active listening Virtual machine lock manager > socket > virtlogd.socket loaded active listening Virtual machine log manager > socket > virtnetworkd.socket loaded active listening Libvirt network local socket Did you restart the VM after running dnf install ? RPM packages cannot start the systemd units in their %post script, they can only register that they exist. The Fedora systemd preset policy sets virtqemud.service to be enabled by default, and if I reboot the cloud image after installing the packages, this works. I see my description was not clear. The issue here is cockpit-machines. Looks like it do not support "Libvirt Modular Daemons". virsh, virt-install and autostart of vm on boot works fine, but cockpit-machines will look if libvirtd.service is running. In Fedora 35 libvirtd.service is not supposed to run because modular daemons is used. You can revert back to monolithic daemon and cockpit-machines will work again. cockpit-machines need to change to support modular daemons to work on Fedora 35. Is it to early to use modular daemons in Fedora as default? Or can cockpit-machines rpm revert back to monolithic daemon on install? Maybe documetation of how to revert until cockpit-machines supports modular daemons. This was addressed upstream in:
commit b59da0d7b1d0dedefab7f0d6ab6678aa7547386a
Author: Katerina Koukiou <kkoukiou>
Date: Mon Sep 20 13:14:49 2021 +0200
Stop trying to guess the name of the libvirt service/socket
And leave the service activation to libvirt itself.
In all our supported distros the libvirt service is socket activated.
The socket is running by default, from the very first moment the user
installs the package. A stopped libvirt socket means that the user
manually changed the default state, and should be left alone to do so.
In addition to that, the libvirt daemon changed recently to a modular
achitecture, so instead of a single monolithic libvirtd daemon we now
get one for each driver (domain, storage, network, interfaces etc). Some distros already
opted in the new modular daemons, (see https://www.mail-archive.com/libvir-list@redhat.com/msg219931.html)
but many keep using the old monolithic libvirtd daemon.
As now we will have many sockets to check for their state, we decided to get
rid of any libvirt service/socket name detection logic from
cockpit-machines.
This logic was previously used to detect if the service was running
and if not we showed the user an empty state screen.
That also helped us to listen to socket/service changes and update
the UI accordingly.
This commit replaces this logic will a simple API call in the initial
render of this app which allows us to check if a connection type is
available; if that fails for any of the system/session connections, that means that the libvirt service is not available for the connection.
For the same reason of the name detection logic being problematic, let's
stop providing to the cockpit-machines users the ability to start/enable
the libvirt service/socket from the cockpit-machines UI directly.
This now allows us to make cockpit-machines work on fedora-35.
which is part of cockpit-machines >= 253 iiuc, so your version is just slightly out of date.
Right, current version is 254, which is supposed to address that: https://bodhi.fedoraproject.org/updates/FEDORA-2021-7ccf08dbe0 This just assumes that the OS will handle it, as everything should be socket activated. Fedora packages not starting enabled services upon installation is slightly irritating, Daniel already explained that. The main thing that tipped me off was your "If you go to command line you can not start libvirtd manual.". That is the bit that I can't reproduce/explain, and need more information about (it's also not directly related to cockpit-machines, but I'm interested anyway) Upgraded to cockpit-machines-254-1.fc35.noarch. It was strange because all other cockpit was 254: cockpit.x86_64 254-1.fc35 @fedora cockpit-bridge.x86_64 254-1.fc35 @fedora cockpit-machines.noarch 252-1.fc35 @fedora cockpit-networkmanager.noarch 254-1.fc35 @fedora cockpit-packagekit.noarch 254-1.fc35 @fedora cockpit-pcp.x86_64 254-1.fc35 @fedora cockpit-selinux.noarch 254-1.fc35 @fedora cockpit-storaged.noarch 254-1.fc35 @fedora cockpit-system.noarch 254-1.fc35 @fedora cockpit-ws.x86_64 254-1.fc35 @fedora Upgraded to 254 from koji. All working as expected with cockpit-machines-254-1.fc35.noarch. Thanks for confirming! Note that cockpit-machines is a separate upstream project/Fedora source package, so its version number does not align with cockpit's. (Same with cockpit-{podman,ostree,subscription-manager,session-recording})
|