[libvirt] Remotable Libvirt

[Pavel Hrdina]

On Thu, May 25, 2017 at 10:26:47AM -0700, Peter 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.

Another thing to consider is what virtualization management
functionality should be implemented in cockpit?  For example if cockpit
would like to handle guest installation in a similar matter as
virt-manager it has to be implemented somewhere.

Libvirt doesn't have any API which would handle the whole installation
process and IMHO it's out of scope of dbus or REST API.  The
installation process in virt-manager handles a lot of different aspects,
for example it can create a new storage/pool, it can download
vmlinuz/initrd from provided URL, it can mount an ISO image, etc.

This logic has to be implemented somewhere and I don't think that
cockpit is a right place.  Currently there is command line tool
virt-install which is part of virt-manager project that is able to
handle all the installation aspects but that's not ideal for cockpit
the same way ho virsh is not ideal.

Another alternative way how to connect cockpit with libvirt could be to
implement some intermediate application which would communicate directly
with libvirt, would handle all the logic that is required by most of the
management application and provide several ways how UI applications can
communicate whit it.  The benefit of this application would be that not
only cockpit would use it but virt-manager could switch to it eventually
and possibly virt-install as well.  This would lead to a single project
that provides virtualization management functionality that can be
reused by other project or tools or simple scripts as well.

Pavel

> 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?
> 
> 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.
> 
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
-------------- 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/20170607/08f4d034/attachment-0001.sig>