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
