[libvirt] Out of band channels

[Chris Lalancette]

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 [1]
> * Any character device [2]
> 
> 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.

-- 
Chris Lalancette