Hi, I am using python libvirt api to get domain information. When using a uri without specifying the socket path, an error occurs. uri = "qemu+ssh://myuser@some.kvm.host/system" conn = libvirt.open(uri) This results in the following: libvirt: XML-RPC error : internal error: received hangup event on socket If I append the socket path to the URI, it works. e.g. qemu+ssh://myuser@some.kvm.host/system?socket=/var/run/libvirt/libvirt-sock Is this the recommended way to construct an ssh uri? My concern is that the socket path may be different when connecting to different libvirt hosts. remote host is ubuntu 20.04 running libvirtd (libvirt) 6.0.0 under systemd - Joe
On Fri, 2020-04-03 at 19:37 -0500, Joe Muro wrote:> Hi, > > I am using python libvirt api to get domain information. When using a uri without specifying the socket path, an error occurs. > > uri = "qemu+ssh://myuser@some.kvm.host/system" > conn = libvirt.open(uri) > > This results in the following: > > libvirt: XML-RPC error : internal error: received hangup event on socket > > If I append the socket path to the URI, it works. e.g. > > qemu+ssh://myuser@some.kvm.host/system?socket=/var/run/libvirt/libvirt-sock > > Is this the recommended way to construct an ssh uri? My concern is that the socket path may be different when connecting to different libvirt hosts. > > remote host is ubuntu 20.04 running libvirtd (libvirt) 6.0.0 under systemdIs the client machine running macOS by any chance? There is a long-standing issue where that platform will use different paths for certain resources, including the libvirtd socket, and the way it currently works is that the default socket path is chosen by the client, so any mismatch will result in something like the above. The plan is to replace our use of nc with a custom virt-nc helper that will link against libvirt on the host side and will thus be able to use the default socket path appropriate for the system; however, as far as I'm aware nobody is currently working on it. -- Andrea Bolognani / Red Hat / Virtualization
On Fri, Apr 03, 2020 at 07:37:19PM -0500, Joe Muro wrote:> > Hi, > > I am using python libvirt api to get domain information. When using a uri > without specifying the socket path, an error occurs. > > uri = "qemu+ssh://myuser@some.kvm.host/system" > conn = libvirt.open(uri) > > This results in the following: > > libvirt: XML-RPC error : internal error: received hangup event on socket > > If I append the socket path to the URI, it works. e.g. > > qemu+ssh://myuser@some.kvm.host/system?socket=/var/run/libvirt/libvirt-sock > > Is this the recommended way to construct an ssh uri? My concern is that the > socket path may be different when connecting to different libvirt hosts.Generally you should *not* need to specify the socket path. The libvirt client will attempt to use the same socket path on the remote host, as it would use on the source host. Note that this assumes that libvirt was built with the same set of --prefix, --localstatedir, --rundir options on both hosts. If that is not the case, then the socket must be given explicitly. 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 :|
On Mon, Apr 06, 2020 at 10:45:49AM +0200, Andrea Bolognani wrote:> On Fri, 2020-04-03 at 19:37 -0500, Joe Muro wrote: > > Hi, > > > > I am using python libvirt api to get domain information. When using a uri without specifying the socket path, an error occurs. > > > > uri = "qemu+ssh://myuser@some.kvm.host/system" > > conn = libvirt.open(uri) > > > > This results in the following: > > > > libvirt: XML-RPC error : internal error: received hangup event on socket > > > > If I append the socket path to the URI, it works. e.g. > > > > qemu+ssh://myuser@some.kvm.host/system?socket=/var/run/libvirt/libvirt-sock > > > > Is this the recommended way to construct an ssh uri? My concern is that the socket path may be different when connecting to different libvirt hosts. > > > > remote host is ubuntu 20.04 running libvirtd (libvirt) 6.0.0 under systemd > > Is the client machine running macOS by any chance? > > There is a long-standing issue where that platform will use different > paths for certain resources, including the libvirtd socket, and the > way it currently works is that the default socket path is chosen by > the client, so any mismatch will result in something like the above. > > The plan is to replace our use of nc with a custom virt-nc helper > that will link against libvirt on the host side and will thus be able > to use the default socket path appropriate for the system; however, > as far as I'm aware nobody is currently working on it.I've got patches which do most of the work, but need some polish and refactoring still to make acceptable. 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 :|
The client machine is running macOS. So that explains it. For my case, hard-coding the socket path is not a major problem, although having libvirt "auto-detect" the correct path would certainly be nice. Thanks for your help. - Joe From: Andrea Bolognani <abologna@redhat.com> To: Joe Muro <joemuro@us.ibm.com>, libvirt-users@redhat.com Date: 04/06/2020 04:47 AM Subject: [EXTERNAL] Re: libvirt remote uri format On Fri, 2020-04-03 at 19:37 -0500, Joe Muro wrote:> Hi, > > I am using python libvirt api to get domain information. When using a uriwithout specifying the socket path, an error occurs.> > uri = "qemu+ssh://myuser@some.kvm.host/system" > conn = libvirt.open(uri) > > This results in the following: > > libvirt: XML-RPC error : internal error: received hangup event on socket > > If I append the socket path to the URI, it works. e.g. > > qemu+ssh://myuser@some.kvm.host/system?socket=/var/run/libvirt/libvirt-sock> > Is this the recommended way to construct an ssh uri? My concern is thatthe socket path may be different when connecting to different libvirt hosts.> > remote host is ubuntu 20.04 running libvirtd (libvirt) 6.0.0 undersystemd Is the client machine running macOS by any chance? There is a long-standing issue where that platform will use different paths for certain resources, including the libvirtd socket, and the way it currently works is that the default socket path is chosen by the client, so any mismatch will result in something like the above. The plan is to replace our use of nc with a custom virt-nc helper that will link against libvirt on the host side and will thus be able to use the default socket path appropriate for the system; however, as far as I'm aware nobody is currently working on it. -- Andrea Bolognani / Red Hat / Virtualization
Maybe Matching Threads
- Re: libvirt remote uri format
- libvirt remote uri format
- Re: Ubuntu 16.04 libvirt-guests.sh [6917] - running guests under URI address default: no running guests
- Re: Ubuntu 16.04 libvirt-guests.sh [6917] - running guests under URI address default: no running guests
- Re: Ubuntu 16.04 libvirt-guests.sh [6917] - running guests under URI address default: no running guests