Re: Remotable Libvirt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 06, 2017 at 06:07:21PM +0200, Stef Walter wrote:
> On 06.06.2017 17:17, Daniel P. Berrange wrote:
> > On Tue, Jun 06, 2017 at 05:11:55PM +0200, Peter Krempa wrote:
> >> On Tue, Jun 06, 2017 at 07:45:10 -0700, Peter wrote:
> >>> On 05/26/2017 02:11 AM, Martin Kletzander wrote:
> >>>> On Thu, May 25, 2017 at 10:16:26AM -0700, Peter Volpe wrote:
> >>
> >> [...]
> >>
> >>>> If we standardize even the smallest part of the RPC, then it might screw
> >>>> us immediately.  We are keeping it private just so we can enhance the
> >>>> APIs we already have.  We don't know when we will need to change some
> >>>> part of it.
> >>>>
> >>>
> >>> How does the current ssh implementation work?
> >>> (https://libvirt.org/remote.html) If clients are able to talk to a remote
> >>> libvirtd via ssh then there must be some sort of compatibility guarantee.
> >>> Otherwise unless the versions are exactly the same clients wouldn't be able
> >>> to talk to remote daemons.
> >>
> >> They use the internal RPC protocol transported over SSH. The client
> >> library initializes the ssh connection to the server, and then starts to
> >> talk the RPC tunelled over the SSH session.
> >>
> >> The compatibility is guaranteed only if you use the client library. As
> >> said, the RPC protocol is considered an internal detail and the client
> >> library shields you from a possible incompatibility if we'd ever make
> >> incompatible change.
> > 
> > Ignoring wire compatibility questions, it is important to note that not all
> > functionality in libvirt is done in libvirtd. There are libvirt drivers that
> > are entirely implemented in the library, not libvirtd. For some of the
> > libvirt drivers that do use libvirtd, there is also still some functionality
> > that is client side.
> 
> So to summarize what I'm hearing here:
> 
>  * There is no libvirt remotable API today.

Libvirt drivers that are implemented in libvirtd are accessible remotely
using the libvirt client library. We just consider the wire protocol a
private impl detail between them.  Drivers implemented outside libvirtd
are often accessible remotely too, via the hypervisor's native remoting
system. 

>  * All libvirt APIs are only able to be used in-process.
>  * There is presently no ability for a libvirt API to be used from a
>    browser, or non-Linux process or non-Linux system.

Actually libvirt can be built on OS-X, Windows and FreeBSD too.

> In order for Cockpit to interact with libvirt, it would need to grow a
> remoteable API. The Cockpit project could likely jumpstart such an
> effort, by lightly wrapping the C API in DBus ... and contribute that
> remoteable API code to the libvirt project.

FWIW, if someone does want to build a DBus wrapper around libvirt, that
would be something todo as a separate code module above the libvirt
API. We would be happy to host such an effort on libvirt.org git though,
alongside other higher level API wrappers. Likewise for a REST API wrapper.

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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux