[libvirt] Out of band channels
clalance at redhat.com
Fri Dec 11 17:03:47 UTC 2009
On 12/11/2009 03:32 PM, Matthew Booth wrote:
> A libvirt client can connect to libvirt on a remote host. However, on
> its own this doesn't give the client a usable level of access. The
> reason for this is that libvirt doesn't expose some critical management
> interfaces. For QEMU this amounts to pretty much anything provided
> directly by the QEMU process, including:
> * VNC console 
> * Any character device 
> I'm undecided as to whether access to underlying storage falls into this
> bucket. It would certainly be convenient in certain circumstances.
> This means, for example that I need out of band access to:
> * See a graphical console
> * Connect to a serial console
> * Connect to a guest channel
> As these are fairly fundamental operations, I wonder if there has been
> any thought towards creating tunnels over a libvirt connection.
> In the first instance, I think this would require a generic method to
> multiplex multiple streams over a single remote connection. This would
> obviously be a significant protocol change. Would a messaging protocol,
> AMQP for instance, be a good candidate here?
In point of fact, we *do* have a way to mulitplex generic data through a
libvirt tunnel; it's how we implemented "tunnelled" migration for
kvm. Look in git for commits referencing "data streams", around August 2009.
I think danpb's plan was to eventually tunnel character devices
(serial console's in particular) over the generic data stream, but
I think that work got preempted by more high priority work.
So I think what you are proposing makes sense, it just needs someone
to sit down and plumb it. If you are gung-ho to do it, the implementation
for tunnelled migration is in src/qemu/qemu_driver.c to use as an example.
More information about the libvir-list