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