RE: libvirt remote uri format
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 To: Joe Muro , 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 uri without specifying the socket path, an error occurs. > > uri = "qemu+ssh://myu...@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://myu...@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. -- Andrea Bolognani / Red Hat / Virtualization
Re: plug pre-created tap devices to libvirt guests
On 4/6/20 9:54 AM, Daniel P. Berrangé wrote: On Mon, Apr 06, 2020 at 03:47:01PM +0200, Miguel Duarte de Mora Barroso wrote: Hi all, I'm aware that it is possible to plug pre-created macvtap devices to libvirt guests - tracked in RFE [0]. My interpretation of the wording in [1] and [2] is that it is also possible to plug pre-created tap devices into libvirt guests - that would be a requirement to allow kubevirt to run with less capabilities in the pods that encapsulate the VMs. I took a look at the libvirt code ([3] & [4]), and, from my limited understanding, I got the impression that plugging existing interfaces via `managed='no' ` is only possible for macvtap interfaces. No, it works for standard tap devices as well. The reason the BZs and commit logs talk mostly about macvtap rather than tap is because 1) that's what kubevirt people had asked for and 2) it already *mostly* worked for tap devices, so most of the work was related to macvtap (my memory is already fuzzy, but I think there were a couple privileged operations we still tried to do for standard tap devices even if they were precreated (standard disclaimer: I often misremember, so this memory could be wrong! But definitely precreated tap devices do work). I think though that when someone from kubevirt actually tried using a precreated macvtap device, they found that their precreated device wasn't visible at all to the unprivileged libvirtd in the pod, because it was in a different network namespace, or something like that. So there may still be more work to do (or, again, my info might be out of date and they figured out a proper solution). Would you be able to shed some light into this ? Is it possible on libvirt-5.6.0 to plug pre-created tap devices to libvirt guests ? [0] - https://bugzilla.redhat.com/show_bug.cgi?id=1723367 This links to the following message, which illustrates how to use pre-create tap and macvtap devices: https://www.redhat.com/archives/libvir-list/2019-August/msg01256.html Laine: it would be useful to add something like this short guide to the knowledge base docs You mean the wiki? Sure, I can do that. (BTW - that was admirable reading / searching / responding - 7 minutes and it wasn't even your patch! How do you do that? :-))
Re: plug pre-created tap devices to libvirt guests
On Mon, Apr 06, 2020 at 10:03:41AM -0400, Laine Stump wrote: > On 4/6/20 9:54 AM, Daniel P. Berrangé wrote: > > > Would you be able to shed some light into this ? Is it possible on > > > libvirt-5.6.0 to plug pre-created tap devices to libvirt guests ? > > > > > > [0] - https://bugzilla.redhat.com/show_bug.cgi?id=1723367 > > This links to the following message, which illustrates how to use pre-create > > tap and macvtap devices: > > > >https://www.redhat.com/archives/libvir-list/2019-August/msg01256.html > > > > Laine: it would be useful to add something like this short guide to the > > knowledge base docs > > > You mean the wiki? Sure, I can do that. No, i mean docs/kbase/ > (BTW - that was admirable reading / searching / responding - 7 minutes and > it wasn't even your patch! How do you do that? :-)) I just read the BZ & followed the link :-) 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: plug pre-created tap devices to libvirt guests
On Mon, Apr 06, 2020 at 03:47:01PM +0200, Miguel Duarte de Mora Barroso wrote: > Hi all, > > I'm aware that it is possible to plug pre-created macvtap devices to > libvirt guests - tracked in RFE [0]. > > My interpretation of the wording in [1] and [2] is that it is also > possible to plug pre-created tap devices into libvirt guests - that > would be a requirement to allow kubevirt to run with less capabilities > in the pods that encapsulate the VMs. > > I took a look at the libvirt code ([3] & [4]), and, from my limited > understanding, I got the impression that plugging existing interfaces > via `managed='no' ` is only possible for macvtap interfaces. > > Would you be able to shed some light into this ? Is it possible on > libvirt-5.6.0 to plug pre-created tap devices to libvirt guests ? > > [0] - https://bugzilla.redhat.com/show_bug.cgi?id=1723367 This links to the following message, which illustrates how to use pre-create tap and macvtap devices: https://www.redhat.com/archives/libvir-list/2019-August/msg01256.html Laine: it would be useful to add something like this short guide to the knowledge base docs 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 :|
plug pre-created tap devices to libvirt guests
Hi all, I'm aware that it is possible to plug pre-created macvtap devices to libvirt guests - tracked in RFE [0]. My interpretation of the wording in [1] and [2] is that it is also possible to plug pre-created tap devices into libvirt guests - that would be a requirement to allow kubevirt to run with less capabilities in the pods that encapsulate the VMs. I took a look at the libvirt code ([3] & [4]), and, from my limited understanding, I got the impression that plugging existing interfaces via `managed='no' ` is only possible for macvtap interfaces. Would you be able to shed some light into this ? Is it possible on libvirt-5.6.0 to plug pre-created tap devices to libvirt guests ? [0] - https://bugzilla.redhat.com/show_bug.cgi?id=1723367 [1] - https://bugzilla.redhat.com/show_bug.cgi?id=1723367#c2 [2] - https://bugzilla.redhat.com/show_bug.cgi?id=1723367#c3 [3] - https://github.com/libvirt/libvirt/blob/master/src/qemu/qemu_interface.c#L434 [4] - https://github.com/libvirt/libvirt/blob/master/src/qemu/qemu_interface.c#L443
Re: libvirt Source RPMs for CentOS or RHEL?
Many Thanks Daniel, Your instructions perfectly works for my build on CentOS and RHEL distro! Cheers FuLong -- FuLong Wang fulong.w...@cn.ibm.com IBM China Systems Lab, Beijing, China ___ On 4/2/20 16:41, Daniel P. Berrangé wrote: On Thu, Apr 02, 2020 at 08:47:30AM +0800, FuLong Wang wrote: Hello Experts, Do we have libvirt source rpms (version above 5.9.0) for CentOS or RHEL? I only find source rpms for fedora in below public link. https://libvirt.org/sources/ Please ignore all the RPMs you see there, they really shouldn't be used. The source tarballs (eg libvirt-5.9.0.tar.xz) contain a spec file inside. This means you can generate RPMs for your precise distro using something akin to the following commands: $ rpmbuild -ts libvirt-5.9.0.tar.xz $ sudo dnf install redhat-rpm-config $ sudo dnf builddep $HOME/rpmbuild/SRPMS/libvirt-5.9.0-1.fc31.src.rpm $ rpmbuild --rebuild $HOME/rpmbuild/SRPMS/libvirt-5.9.0-1.fc31.src.rpm Regards, Daniel
Re: libvirt remote uri format
On Mon, 2020-04-06 at 09:49 +0100, Daniel P. Berrangé wrote: > On Mon, Apr 06, 2020 at 10:45:49AM +0200, Andrea Bolognani wrote: > > 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. That's great news! :) -- Andrea Bolognani / Red Hat / Virtualization
Re: libvirt remote uri format
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://myu...@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://myu...@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 :|
Re: libvirt remote uri format
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://myu...@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://myu...@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 :|
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 uri > without specifying the socket path, an error occurs. > > uri = "qemu+ssh://myu...@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://myu...@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. -- Andrea Bolognani / Red Hat / Virtualization
