[libvirt] Remotable Libvirt

Peter petervo at redhat.com
Tue Jun 6 14:45:10 UTC 2017

On 05/26/2017 02:11 AM, Martin Kletzander wrote:
> On Thu, May 25, 2017 at 10:16:26AM -0700, Peter Volpe wrote:
>> Hi Everyone,
>> We are working towards building on the virtualization management
>> functionality in cockpit (http://cockpit-project.org/) and wanted to get
>> some feedback on the best way to integrate with libvirt.
>> As a quick overview, cockpit aims to talk to existing remotable system
>> APIs. Usually these API’s take the form of dbus, REST or executable
>> commands. The majority of cockpit is implemented in javascript. There is
>> no cockpit backend that knows how to change a hostname for example. The
>> cockpit backend knows how to handle a dbus payload. The javascript
>> running in the users browser knows how to use the systemd dbus API at
>> org.freedesktop.hostname1 to manage the system hostname.
>> Right now some of the basics have been implemented by spawning commands
>> on the system. This isn't ideal because it involves parsing / screen
>> scraping output and doesn't support receiving events so we have to poll
>> (ei run the command again) to keep the UI up to date.
>> As far as I know libvirt doesn't currently have a remoteable API. It
>> does have a daemon that communicates with clients via a XDR RPC.
>> (https://libvirt.org/internals/rpc.html) However from what I'm hearing
>> the RPC is considered an internal implementation and shouldn't be used
>> by external applications. Is that still the case? Is there any chance of
>> getting talking the daemon directly using the XDR standard for a subset
>> of methods blessed as part of the externally supported API?
> 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.

More information about the libvir-list mailing list