Re: libvirtd: failed to connect to socket after installation

On Thu, Sep 08, 2022 at 11:07:30 -0500, Carlos Bilbao wrote: > Hello, made some progress and I think I see what the issue may be now... > and it looks like virt-install's fault. > >>> Regardless of all that, the client is trying to connect to virtqemud >>> but you seem to have the monolithic libvirtd daemon running. I can't >>> remember whether that's expected, but it's looks like a red flag to >>> me. I think the client might have gotten confused about whether split >>> daemons are in use. >>> >>> Please check out

> and ensure you're >>> in one of the two supported deployment scenarios and not a weird mix >>> of the two. >> > > So, I started again from scratch. Deleted absolutely everything that had > to do with libvirt. I also had to unmask a bunch of service-related

> that were on masked state: > > for ANNOYING_SERVICE in libvirtd virtlogd.socket virtlogd.service \ >         virtlockd.socket virtlockd.service virtlogd-admin.socket > virtlockd-admin.socket > do >         systemctl unmask $ANNOYING_SERVICE > done > > So, after doing this, building and installing the tree, reloading the > daemon, and starting all services and sockets again, I finally get an > active libvirtd daemon: > > # systemctl status libvirtd > ● libvirtd.service - Virtualization daemon >      Loaded: loaded (/usr/local/lib/systemd/system/libvirtd.service; > enabled; vendor preset: enabled) >      Active: active (running) since Thu 2022-09-08 15:51:39 UTC;

> ago >        Docs: man:libvirtd(8) >

>    Main PID: 2429457 (libvirtd) >       Tasks: 20 (limit: 32768) >      Memory: 55.6M >         CPU: 28ms >      CGroup: /system.slice/libvirtd.service >              ├─   2760 /usr/sbin/dnsmasq > --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro > --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper >              ├─   2761 /usr/sbin/dnsmasq > --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro > --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper >              └─2429457 /usr/local/sbin/libvirtd --timeout 120 > > Sep 08 15:51:39 host systemd[1]: Starting Virtualization daemon... > Sep 08 15:51:39 host systemd[1]: Started Virtualization daemon. > # > > Now, this is when things get interesting... The next step is testing > virt-install. Since I removed it, I proceed to install again: > > # sudo apt install -y virtinst > (...) > Unpacking virtinst (1:4.0.0-1) ... > Setting up libvirt-glib-1.0-data (4.0.0-2) ... > Setting up libvirt0:amd64 (8.0.0-1ubuntu7.1) ... > Setting up libvirt-glib-1.0-0:amd64 (4.0.0-2) ... > Setting up python3-libvirt (8.0.0-1build1) ... > Setting up libvirt-clients (8.0.0-1ubuntu7.1) ... > Setting up libvirt-daemon-driver-qemu (8.0.0-1ubuntu7.1) ... > Setting up virt-viewer (7.0-2build2) ... > Setting up libvirt-daemon (8.0.0-1ubuntu7.1) ... > Setting up virtinst (1:4.0.0-1) ... > > As you can see, virtinst also installs the libvirt daemon. I didn't

> this would be an issue because the libvirtd daemon running is still my > version. However, when I try to do virt-install I get: > > # virt-install --connect qemu:///system --name ubuntu-sev \ > --boot

> \ > --vcpus 8 --memory 4096 --memtune hard_limit=16777216 \ > --disk pool=default,device=disk,size=32,format=raw \ > --controller type=scsi,model=virtio-scsi  --network > bridge=virbr0,model=virtio \ > --controller type=virtio-serial --machine q35 --cpu host-passthrough \ > --cdrom /var/lib/libvirt/images/ubuntu.iso --osinfo

> --launchSecurity sev,policy=0x00 --graphics none --tpm none > ERROR    Failed to connect socket to

> such file or directory > # > > So, back to square one. However, notice that virtqemud is one of the

> daemons. So, I believe that what happens is that virt-install assumes > libvirt is using the new daemon mode. Is this something that can be > configured? I don't see that option in the man pages of virt-install. You seem to have explicitly started 'libvirtd' service. If that is the case the error message above is actually a bit cryptic, but in fact means that the 'qemu' driver was not compiled. This is because by default it's marked as optional and compiled only if you have all dependencies installed. You need to pass '-Ddriver_qemu=enabled' to the meson configure step to force-enable it. Meson will report what's missing.