Re: Can RHEL7 VM run remote commands to Fedora36 host?

2022-07-29 Thread Carol Bouchard
The only reason I toggled libvirtd was because the remote virsh commands
failed and
I could see the socket didn't exist.  That suggests to me that virtproxyd
wasn't up AND
it was configured at disabled.

Your help was extremely appreciated!  My test tool works now.  So now I can
test outside customer
environment.  This test tool is very important to me and my customers so I
don't break them.

Carol

Carol

On Fri, Jul 29, 2022 at 8:02 AM Daniel P. Berrangé 
wrote:

> On Fri, Jul 29, 2022 at 07:49:16AM -0400, Carol Bouchard wrote:
> > 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.
>
> Enabling/disabling libvirtd probably interfered with virtproxyd, as
> they both want the same sockets.
>
> 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 :|
>
>


Re: Can RHEL7 VM run remote commands to Fedora36 host?

2022-07-29 Thread Daniel P . Berrangé
On Fri, Jul 29, 2022 at 07:49:16AM -0400, Carol Bouchard wrote:
> 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.

Enabling/disabling libvirtd probably interfered with virtproxyd, as
they both want the same sockets.

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 :|



Re: Can RHEL7 VM run remote commands to Fedora36 host?

2022-07-29 Thread Carol Bouchard
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é 
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 :|
>
>


Re: Can RHEL7 VM run remote commands to Fedora36 host?

2022-07-29 Thread Daniel P . Berrangé
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 :|



Re: Can RHEL7 VM run remote commands to Fedora36 host?

2022-07-29 Thread Erik Skultety
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



Re: Can RHEL7 VM run remote commands to Fedora36 host?

2022-07-29 Thread Erik Skultety
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)"
...

$

> 
> Carol