[libvirt] Remotable Libvirt

[Martin Kletzander]

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.

>An alternative is to implement a standards based remotable API, using
>something like dbus or REST, that can be used by external applications.
>I imagine that this would be at a bit of a higher level than the current
>RPC and contain at least some of the logic around the actions it
>performs rather than being a direct passthrough to the daemon.
>
>Of course that is a pretty big undertaking and would, in my opinion,
>only be worth it if there is broader interest in the community and use
>cases beyond what cockpit would like to.
>

I was thinking of adding a REST API to libvirt for some time, actually.
It was supposed to be April fools patch because I didn't know about many
people who would actually like that.  But it could've been made so that
there doesn't need to be much updated if new API arises.  And there are
lot of things already implemented for JSON and the structures and types
we already use in libvirt.  I never got around to doing that, though.

Nowadays, when thinking about this, there could be another layer of
abstraction between libvirt and consumers, and I understand REST would
fit a lot of them.  Even though there would be some code duplication
from what already exists in libvirt, it might be worth it, I don't know.
I'm also not completely sure how much should be abstracted, but I feel
like not only cockpit, but oVirt and OpenStack (heck, maybe even
virt-manager) could benefit from such tool as well.  Maybe all of you
could weigh in.  I might, actually, be really interested in such a
project.  That is if it shows that there is use for it (we all have
enough side projects that there is little to no use for them, right ;)),
so feel free to discuss the ideas to more detail.

Have a nice day,
Martin

P.S.: Since you started the discussion as the first one, I would suggest
      paying homage to the cockpit project by naming it CockVirt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170526/bb768fc9/attachment-0001.sig>