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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list