Install libvirt-daemon-kvm on Fedora rawhide by "dnf install libvirt-daemon-kvm". Start libvirtd service failed with error "Failed to start libvirtd.service: Unit libvirtd.service not found." Package "libvirt-daemon" is not installed and this package is not required by libvirt-daemon-kvm in rawhide anymore. Version: libvirt-daemon-kvm-9.3.0-1.fc39.x86_64 Reproducible: Always Steps to Reproduce: 1. Deploy Fedora rawhide VM. 2. dnf install libvirt-daemon-kvm 3. systemctl start libvirtd Actual Results: Start libvirtd service failed with error "Failed to start libvirtd.service: Unit libvirtd.service not found." Expected Results: Service libvirtd should get started.
There are many changes done by @crobinso since last F38 build. This caused problem and now when I updated my F38 Silverblue to F39 Silverblue, I am not able to run virtual machines. I need to fix few things like described in initial comment here like pulling libvirt-daemon then starting libvirtd service along with virtnetworkd.socket service. Finally my VM's are back to work.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle. Changing version to 39.
This is expected since libvirt switched to defaulting to modular daemons. More details here: https://fedoraproject.org/wiki/Changes/LibvirtModularDaemons Basically, monolithic libvirtd.service is not installed by default, in favor of fine grained daemons virtqemud, virtnetworkd, virtstoraged, etc. So it's expected that the combined libvirtd binary is not pulled in by the libvirt-daemon-kvm metapackage. @
@pnemade it sounds like you're seeing an upgrade issue, there could be a bug there when going from f38 to f39. given the above comment, can you isolate what specifically went wrong? did you have libvirt-daemon installed before but now it's not working? There has been some libvirt daemon weirdness caused by a systemd regression that is since fixed, maybe you were hitting that: https://github.com/systemd/systemd/issues/27953
Luckily i have saved the terminal log of upgrading Fedora 38 Silverblue to Fedora 39 Silverblue $ cat Silverblue-38-to-39.txt |grep libvirt Upgraded: libvirt-client 9.0.0-3.fc38 -> 9.6.0-1.fc39 libvirt-daemon-config-network 9.0.0-3.fc38 -> 9.6.0-1.fc39 libvirt-daemon-driver-interface 9.0.0-3.fc38 -> 9.6.0-1.fc39 libvirt-daemon-driver-network 9.0.0-3.fc38 -> 9.6.0-1.fc39 libvirt-daemon-driver-nodedev 9.0.0-3.fc38 -> 9.6.0-1.fc39 libvirt-daemon-driver-nwfilter 9.0.0-3.fc38 -> 9.6.0-1.fc39 libvirt-daemon-driver-qemu 9.0.0-3.fc38 -> 9.6.0-1.fc39 libvirt-daemon-driver-secret 9.0.0-3.fc38 -> 9.6.0-1.fc39 libvirt-daemon-driver-storage 9.0.0-3.fc38 -> 9.6.0-1.fc39 libvirt-daemon-driver-storage-core 9.0.0-3.fc38 -> 9.6.0-1.fc39 libvirt-daemon-driver-storage-disk 9.0.0-3.fc38 -> 9.6.0-1.fc39 libvirt-daemon-driver-storage-gluster 9.0.0-3.fc38 -> 9.6.0-1.fc39 libvirt-daemon-driver-storage-iscsi 9.0.0-3.fc38 -> 9.6.0-1.fc39 libvirt-daemon-driver-storage-iscsi-direct 9.0.0-3.fc38 -> 9.6.0-1.fc39 libvirt-daemon-driver-storage-logical 9.0.0-3.fc38 -> 9.6.0-1.fc39 libvirt-daemon-driver-storage-mpath 9.0.0-3.fc38 -> 9.6.0-1.fc39 libvirt-daemon-driver-storage-rbd 9.0.0-3.fc38 -> 9.6.0-1.fc39 libvirt-daemon-driver-storage-scsi 9.0.0-3.fc38 -> 9.6.0-1.fc39 libvirt-daemon-driver-storage-zfs 9.0.0-3.fc38 -> 9.6.0-1.fc39 libvirt-daemon-kvm 9.0.0-3.fc38 -> 9.6.0-1.fc39 libvirt-glib 4.0.0-8.fc38 -> 4.0.0-9.fc39 libvirt-libs 9.0.0-3.fc38 -> 9.6.0-1.fc39 python3-libvirt 9.0.0-2.fc38 -> 9.6.0-1.fc39 Removed: libvirt-daemon-9.0.0-3.fc38.x86_64 Added: libvirt-daemon-common-9.6.0-1.fc39.x86_64 libvirt-daemon-lock-9.6.0-1.fc39.x86_64 libvirt-daemon-log-9.6.0-1.fc39.x86_64 libvirt-daemon-plugin-lockd-9.6.0-1.fc39.x86_64 libvirt-daemon-proxy-9.6.0-1.fc39.x86_64 About systemd package, I see below in logs, so systemd was not the issue when my system is upgraded. Upgraded: systemd 253.7-1.fc38 -> 254-1.fc39 I don't know if this was correct upgrade happened for libvirt packages or there was an issue with the F39 compose which I used to upgrade. After that I managed to get libvirt service up and running by installing libvirt-daemon package. I also need to enable other services virtnetworkd.service and virtstoraged.service
I can't find anything in libvirt spec that should have caused libvirt-daemon to be removed. What command did you use to update silverblue? Maybe whatever method it uses removed libvirt-daemon, since it's not the default setup anymore. I don't really know where to check to figure that out though.
On existing Fedora 38 Silverblue installation, I added/layered virt-install and virt-manager packages. This worked fine for whole F38 branching to F39 branching updates. Then when F39 branching happened and successful composes came for F39, I upgraded to F39 using commands ostree remote refs fedora sudo ostree admin pin 0 rpm-ostree rebase fedora:fedora/39/x86_64/silverblue I already shared relevant lines from upgrade command output for virt package updates. To reproduce this issue, someone with F38 Silverblue installed, run following command rpm-ostree install virt-install virt-manager reboot and then check if one can use virtual machines on F38 Then upgrade to F39 Silverblue and check again if one can use virtual machines or not If virtual machines are working then good if not then check for libvirt-daemon package installed or not. I don't have any machine now to reproduce this issue.
This is kind of a long shot, but is it possible that at the time when the upgrade was performed Rawhide / Fedora 39 was still set up so that DNF5 was the default package manager, and that version of DNF is more aggressive than the old one when it comes to removing packages that are no longer considered necessary? With the libvirt-daemon-kvm -> libvirt-daemon dependency now gone, it could make sense from the package manager's point of view to get rid of the latter package.
@pnemade can you please confirm whether the Silverblue image for Fedora 39 contains the passt and passt-selinux packages? What about libvirt-daemon-proxy and nmap-ncat? As part of Bug 2232805 I have determined that we probably need at least a weak dependency on libvirt-daemon in order to keep existing setups working on upgrade. This seems to work fine on regular Fedora, but I don't have a Silverblue installation handy and I don't know if things work much differently there. The packages I've listed above are those that libvirt has a weak dependency on already, so if those are included in the latest Silverblue image I think that there's a pretty good chance that the patch I've prepared will take care of Silverblue too.
I almost daily update my Silverblue system and if you know each update itself adds or removes packages as its daily ostree compose happens. Right now I have recent update installed of 28th August. Let me check on this update tree. $ rpm -qa passt passt-selinux passt-0^20230818.g0af928e-1.fc39.x86_64 passt-selinux-0^20230818.g0af928e-1.fc39.noarch $ rpm -qa libvirt-daemon-proxy nmap-ncat libvirt-daemon-proxy-9.6.0-1.fc39.x86_64 so I don't have nmap-ncat installed on Silverblue 39.20230828.n.0 update
(In reply to Parag Nemade from comment #10) > I almost daily update my Silverblue system and if you know each update > itself adds or removes packages as its daily ostree compose happens. > Right now I have recent update installed of 28th August. Let me check on > this update tree. > > $ rpm -qa passt passt-selinux > passt-0^20230818.g0af928e-1.fc39.x86_64 > passt-selinux-0^20230818.g0af928e-1.fc39.noarch This matches my expectations. > $ rpm -qa libvirt-daemon-proxy nmap-ncat > libvirt-daemon-proxy-9.6.0-1.fc39.x86_64 > > so I don't have nmap-ncat installed on Silverblue 39.20230828.n.0 update This doesn't. Can you please run $ rpm -qf /usr/bin/nc The Recommends in libvirt-daemon-proxy is actually for the nc binary, not the nmap-ncat package itself, and there are a number of packages in Fedora that can provide it. Perhaps Silverblue uses a different one.
$ rpm -qf /usr/bin/nc netcat-1.225-2.fc39.x86_64
(In reply to Parag Nemade from comment #12) > $ rpm -qf /usr/bin/nc > netcat-1.225-2.fc39.x86_64 Thanks! This seems to confim that weak dependencies are included in Silverblue composes, and thus that the upstream fix commit aa5895cbc72bd9b4bb1ce99e231b2ac4b25db9c4 Author: Andrea Bolognani <abologna> Date: Wed Aug 30 17:45:47 2023 +0200 rpm: Recommend libvirt-daemon for with_modular_daemons distros A default deployment on modern distros uses modular daemons but switching back to the monolithic daemon, while not recommended, is still considered a perfectly valid option. For a monolithic daemon deployment, the upgrade to libvirt 9.2.0 or newer works as expected; a subsequent call to dnf autoremove, however, results in the libvirt-daemon package being removed and the deployment no longer working. In order to avoid that situation, mark the libvirt-daemon as recommended. This will unfortunately result in it being included in most installations despite not being necessary, but considering that the alternative is breaking existing setups on upgrade it feels like a reasonable tradeoff. Moreover, since the dependency on libvirt-daemon is just a weak one, it's still possible for people looking to minimize the footprint of their installation to manually remove the package after installation, mitigating the drawbacks of this approach. https://bugzilla.redhat.com/show_bug.cgi?id=2232805 Signed-off-by: Andrea Bolognani <abologna> Reviewed-by: Erik Skultety <eskultet> Reviewed-by: Daniel P. Berrangé <berrange> v9.7.0-rc2-2-gaa5895cbc7 will address the problem you've reported too. Cole, I'm assigning this to you with the same rationale as Bug 2232805: it's a Fedora bug that will be addressed via the upcoming rebase to libvirt 9.7.0.
Fedora 39 has been released with libvirt 9.7.0, which contains the fix for this bug. Closing.