[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] Remotable Libvirt



On Wed, May 31, 2017 at 09:22:41AM -0700, Peter wrote:
> The javascript is always run in the users browser. The dbus calls or
> system commands are sent by the javascript via a websocket to
> cockpit-ws. It then forwards those messages on to the correct
> cockpit-bridge. Based on the payload the bridge knows how
> communicate with the appropriate system API. (See https://github.com/cockpit-project/cockpit/blob/master/doc/protocol.md
> or run 'cockpit-bridge --version' for a list).
> 
> So in keeping with the cockpit ideals cockpit-bridge should not know
> how to start a virtual machine or link to the libvirt library. It
> should receive a payload that when properly executed by the bridge
> results in the machine starting. Right now this is only possible
> using the virsh type commands that have the problems discussed
> earlier. I think it's clear that the existing RPC is not an option.
> So that pretty much leaves us with the choice to roll or own
> solution or to add a more generic dbus or rest wrapper for libvirt.

Thanks - that's a bit clearer now.

I agree with others that as things stand you will need a REST or DBus
or similar API added to libvirt.

However have you considered using gobject-introspection to generate
new "Payload" types automatically?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]