On Fri, Jul 29, 2022 at 08:18:17AM +0200, Erik Skultety wrote: > On Wed, Jul 27, 2022 at 01:18:00PM -0400, Carol Bouchard wrote: > > I have a Fedora36 laptop which hosts VMs with RHEL7 using libvirt. One of > > the RHEL7 VMs, runs remote commands (as root) to 'start' another VM by > > way of my laptop. In other words, the following command is run: > > virsh --connect 'qemu+ssh://192.168.120.1/system' start > > beaker-test-vm1.beaker > > If I run non-remote version of the command on the laptop, it is successful. > > For example, > > virsh --connect qemu:///system start beaker-test-vm1.beaker <-- Successful > > on laptop. > > > > If I do a query like the following *(notice socket use)*, it is successful. > > virsh -d0 --connect > > 'qemu+ssh://192.168.120.1/system?*socket*=/var/run/libvirt/libvirt-sock-ro' > > domstate beaker-test-vm1.beaker > > > > Without socket, I get the following error: > > > > *error: failed to connect to the hypervisor* > > > > *error: End of file while reading data: Ncat: No such file or directory.: > > Input/output error* > > > > This does not work for 'start' because I believe this is a read-only socket > > since I see the error: > > error: Failed to start domain beaker-test-vm1.beaker > > error: operation forbidden: read only access prevents virDomainCreate > > > > When I look at my laptop, there is no /var/run/libvirt/libvirt-sock. > > So.....I've been wondering > > whether RHEL7 virsh/libvirt is compatible with Fedora36. Is there a > > work-around? I can't > > change the distros on my laptop or VMs. > > Hello, > since Fedora 35 libvirt has used the modular daemons architecture. What this > means for you (and appears very confusing) is that when you try starting a VM > locally on your F36 laptop, your virsh client doesn't connect to libvirt-sock > anymore, there's a dedicated connection socket for each of the daemons now and > instead will connect to virtqemud-sock. > Now, old virsh clients like the one you have on your RHEL7 don't know about > this and expect to connect to libvirt-sock instead. In order to create that > socket and restore functionality for old clients you need to start and enable > the virtproxyd.socket systemd unit which proxies old client connections to the > new sockets we have. Why the virtproxyd socket isn't running by default unless > you disabled it beats me, since: > > $ systemctl status virtproxyd > Loaded: loaded (/usr/lib/systemd/system/virtproxyd.socket; enabled; vendor preset: enabled) > ^^^here^^^ > > is set correctly after installation. > Anyhow, just do: > $ sudo systemctl enable --now virtproxyd.socket > > on your laptop and you're good to go > > Regards, > Erik > > So, if you don't have the libvirt-sock created that means the virtproxyd.socket > systemd unit isn't active. Just enable the socket and try again. > > Here, I simulated it for you with my VMs: > > VM1: > $ cat /etc/os-release > NAME="Fedora Linux" > VERSION="36 (Thirty Six)" > ... Uhm, sorry for the noise in ^this very last paragraph, it's a leftover draft of my response... Erik
