Re: libvirtd: failed to connect to socket after installation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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%7C50dc7866a7034346731108da90ecc0ac%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637981643769774692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ICnGUQ5%2BktKFZNx9kp2KvTCajLXKgzsL2uh3Fh%2FKBsY%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://libvirt.org
>    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.




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux