Daniel P. Berrangé
2022-Jul-29 08:43 UTC
Can RHEL7 VM run remote commands to Fedora36 host?
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 is peculiar, it suggests that /var/run/libvirt/libvirt-sock does not exist, while /var/run/libvirt/libvirt-sock-ro does exist. This ought to be an impossible situation in general. As Erik says, In Fedora 36 we have the moduler daemons, so these two sockets are provided by 'virtproxyd.socket' and 'virtproxyd-ro.socket' unit files, so make sure both of those are running. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
TY VM!!! virtproxyd was disabled and I can assure you I didn't disable it. /run/libvirt/libvirt-sock now exists AND the remote virsh actions were successful. Background on my fedora36 install. I did not do an upgrade. This was a fresh install on a new laptop. I could see libvirt was running so I assumed it was intact. I had enabled/disabled libvirtd only because my remote virsh commands were not working. BTW I can't do the ssh approach as the scripts are used by other teams and I could break them. There had to be a better solution and use of proxy is an good one. Carol On Fri, Jul 29, 2022 at 4:43 AM Daniel P. Berrang? <berrange at redhat.com> 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 is peculiar, it suggests that > > /var/run/libvirt/libvirt-sock > > does not exist, while /var/run/libvirt/libvirt-sock-ro does exist. > > This ought to be an impossible situation in general. As Erik says, > In Fedora 36 we have the moduler daemons, so these two sockets are > provided by 'virtproxyd.socket' and 'virtproxyd-ro.socket' unit > files, so make sure both of those are running. > > With regards, > Daniel > -- > |: https://berrange.com -o- > https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- > https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- > https://www.instagram.com/dberrange :| > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20220729/0612a7b9/attachment.htm>