Re: [libvirt] Remotable Libvirt

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.

* 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.

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.