wirelessduck--- wrote:
> I'm having trouble running virsh under runit-init.
>
> It was working previously under sysvinit-core, but after I install
> runit-init and reboot I can no longer access the hypervisor.

I don't know much detail but I know how I would start to debug this.
On a sysvinit booted system I would look for running processes related
to libvirt.

    root@calamity:~# ps -efH | grep libvirt
    root      1657     1  0 Sep09 ?        00:05:18   /usr/sbin/libvirtd -d
    libvirt+  3651     1 38 Sep09 ?        4-01:18:14   qemu-system-x86_64 -enable-kvm -name guest=...

On a working system "libvirtd -d" is running in deamon mode.

    root@calamity:~# lsof -p 1657 | grep -i -e sock -e stream
    libvirtd 1657 root  mem       REG               8,18    97464  135073016 /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.62.0
    libvirtd 1657 root   11u     unix 0xffff922018c85400      0t0      18513 /var/run/libvirt/libvirt-sock type=STREAM
    libvirtd 1657 root   12u     unix 0xffff922017582400      0t0      18515 /var/run/libvirt/libvirt-sock-ro type=STREAM
    libvirtd 1657 root   13u     unix 0xffff922015ee6400      0t0      18517 /var/run/libvirt/libvirt-admin-sock type=STREAM
    libvirtd 1657 root   15u     unix 0xffff922018e0f000      0t0      18550 type=STREAM
    libvirtd 1657 root   16u     sock                0,8      0t0      16620 protocol: TCP
    libvirtd 1657 root   22u     unix 0xffff921fcfd63c00      0t0      29737 /var/run/libvirt/libvirt-sock type=STREAM
    libvirtd 1657 root   26u     unix 0xffff922017582800      0t0      30981 type=STREAM

    root@calamity:~# strace -v virsh list 2>&1 | grep sock
    socket(AF_UNIX, SOCK_STREAM, 0)         = 5
    connect(5, {sa_family=AF_UNIX, sun_path="/var/run/libvirt/libvirt-sock"}, 110) = 0
    getsockname(5, {sa_family=AF_UNIX}, [128->2]) = 0

    root@calamity:~# ll /var/run/libvirt/libvirt-sock
    srwxrwxrwx 1 root root 0 Sep  9 19:48 /var/run/libvirt/libvirt-sock

It uses /var/run/libvirt/libvirt-sock for communications. That's the
area where things are failing for you. The client virsh can't connect
to the running libvirtd daemon.

    root@calamity:~# dpkg -S /etc/init.d/libvirtd
    libvirt-daemon-system: /etc/init.d/libvirtd

    root@calamity:~# dpkg -L libvirt-daemon-system | grep /etc/ | grep /etc/init.d/
    /etc/init.d/libvirt-guests
    /etc/init.d/libvirtd
    /etc/init.d/virtlogd

    root@calamity:~# dpkg -L libvirt-daemon-system | grep /etc/ | less

In the case of libvirtd AFAIK there is only sysvinit scripts. Which
means runit will be running them in legacy compatibility mode. That
seems to be the likely part where things are not working.

I would boot runit and then look to see how things are different. Is
the libvirtd running? Are there are any error messages at boot time
around the running of those scripts. Then to further debug run those
scripts manually. Trace them.

    root@calamity:~# ll /etc/init.d/libvirtd
    -rwxr-xr-x 1 root root 5600 Oct  1  2020 /etc/init.d/libvirtd

    root@calamity:~# less /etc/init.d/libvirtd

    root@calamity:~# service libvirtd status
    Checking status of libvirt management daemon: libvirtd not running.

    root@calamity:~# service libvirtd start

One should normally use "service" to start and stop init scripts
because it cleans the environment, changes directory, and so forth.
All needed things. Of course runit also has a native interface. For
more debugging I would run the script directly tracing it.

    root@calamity:~# sh -x /etc/init.d/libvirtd

That will produce a lot of shell tracing output. I can't really
speculate more without more detail. Hopefully by looking at what it
is doing the reason for it not doing it under runit will become
apparent. It might be a problem with the required cgroups setup. It
might be a different problem. Check the syslog to see what errors are
logged there.

    root@calamity:~# less /var/log/syslog

Hope that helps!

Bob