[libvirt] Out of band channels

Matthew Booth mbooth at redhat.com
Fri Dec 11 14:32:36 UTC 2009

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?

Secondly, I think interfaces which currently create local resources 
should have a default which is managed by libvirt itself. So you'd have:

   <target port='0'/>


<serial type='managed'>
   <target port='0'/>

This would cause libvirt to create whichever host-side chardev is most 
convenient to it and connect itself. The API would then expose read and 
write APIs for the named connection. e.g:

virDomainFoo foo;[3]
if = virDomainGetFoo(domain, "serial0");
bytesIn = virDomainFooRead(foo, &buf, sizeof(buf));

A client application could expose this in a variety of ways locally.


[1] There's an open RFE for this one: 

[2] e.g.
virsh # console RHEL3.FV.64.IDE
error: Cannot connect to a remote console device

[3] What would you call it?
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

M:       +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

More information about the libvir-list mailing list