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.or... 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.or...
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
On 9/8/22 11:12, Peter Krempa wrote: 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