[libvirt] Remotable Libvirt

[Peter]

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.