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