libvirtd: failed to connect to socket after installation

Thu Sep 8 20:45:56 UTC 2022

On 9/8/22 11:12, Peter Krempa wrote:
 > 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 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flibvirt.org%2Fdaemons.html&data=05%7C01%7Ccarlos.bilbao%40amd.com%7C682b310adbe74107f4fd08da91b4e994%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637982503444307132%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=u78aJLvAqCey0vk%2B6drcxatNvjZkHQX2q7FplADDHiI%3D&reserved=0
 >> 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 
stuff
 >> 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; 
1min 30s
 >> ago
 >>        Docs: man:libvirtd(8)
 >> 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flibvirt.org%2F&data=05%7C01%7Ccarlos.bilbao%40amd.com%7C682b310adbe74107f4fd08da91b4e994%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637982503444307132%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=f5qoDhV5n6pFQO3q7SCVt6Wr5ideZ%2BDTyDTASM%2Fcajg%3D&reserved=0
 >>    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 
think
 >> 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 
loader=/usr/share/OVMF/OVMF_CODE.fd,loader.readonly=yes,loader.type=pflash,nvram.template=/usr/share/OVMF/OVMF_VARS.fd,loader_secure=no
 >> \
 >> --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 
detect=on,require=on \
 >> --launchSecurity sev,policy=0x00 --graphics none --tpm none
 >> ERROR    Failed to connect socket to 
'/var/run/libvirt/virtqemud-sock': No
 >> such file or directory
 >> #
 >>
 >> So, back to square one. However, notice that virtqemud is one of the 
modular
 >> 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.
 >

Yep, passing -Ddriver_qemu=enabled compiled all the Qemu stuff. Then,
after starting the new libvirtd daemon, I was able to start 
virtqemud.socket,
which in turn fixed this error when using virt-install.

Thanks,
Carlos