Re: [libvirt] Remotable Libvirt

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.