On Tue, Jun 06, 2017 at 01:25:08PM -0400, Stef Walter wrote: > On 06.06.2017 12:13, Daniel P. Berrange wrote: > > On Tue, Jun 06, 2017 at 06:07:21PM +0200, Stef Walter wrote: > >> 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. > > I believe those are implementation details, not and remoteable API. > Libvirt and its API must always be used in process today? Even though it > RPC may be in play, it is an implementation detail, not API. Correct? I don't really know what distinction your trying to make by saying "used in process". Libvirt provides an ELF library and apps link to it to use it, or use it indirectly via a higher level language specific wrapper. > >> * 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. > > Ah good to know. But the API is always used in process, correct? Again I don't know what you're trying to say here. It is an ELF library and you link to it and call APIs as you would for any other library. > >> 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. > > This would be a useful division of labor between Cockpit consuming such > a remotable API ... and the remoteable API being hosted and maintained > by the libvirt folks ... although the Cockpit project could help get it > started. FWIW, in our RPC system, we auto-generate some of the marshalling code from the API description XML file in /usr/share/libvirt/libvirt-api.xml Some APIs are not friendly for auto-generating though, so probably get about 75% auto-generated and the rest need to be done by hand. 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
