[Xen-devel] libvirt, libxl and <channels>

[Dave Scott <Dave.Scott@xxxxxxxxxx>]

Hi,

Two of the applications I’d like to use with libvirt (cloudstack and oVirt) 
make use of “<channels>” in the domain XML, like this:

<channel type='unix'>
<source mode='bind' path='/var/lib/libvirt/qemu/s-4-VM.agent'/>
<target type='virtio' name='s-4-VM.vport'/>
<address type='virtio-serial'/>
</channel>

I don’t believe these are currently supported by libvirt + libxl — I’d like to 
see what it would take to hook these up.

I chatted with Daniel Berrange at the Xen hackathon last week, and if I 
understood correctly these channels are analogous to serial ports used for 
low-bandwidth communication to (e.g.) guest agents. Daniel suggested that the 
xen console mechanism ought to be adequate to power these things. The other 
option (if higher bandwidth was required) would be to use the Xen vchan 
protocol.

I think the behaviour is:
* bind a unix domain socket on the host (‘/var/lib/libvirt/qemu/…')
* connect a bidirectional low-bandwidth channel to the guest
* manifest the channel in the guest as a ‘/dev/vport/s-4-VM.vport’ device (?)

So an application on the host can connect() to the host socket, an application 
in the guest can open() the guest device and they can talk privately. [Have I 
got this right?]

I had a quick read of the libxl code and I think the consoles are considered an 
internal detail: there is a function libxl_console_get_tty to retrieve a 
console’s endpoint in dom0 but I couldn’t see a way to request additional 
consoles are created. The libxl_domain_config has disks, nics, pcidevs, vfbs, 
vkbs, and vtpms but no consoles. (Have I missed something?)

Bypassing libxl I was able to manually create a 
/local/domain/%d/device/console/1 which was recognised by the VM as /dev/hvc1. 
As an aside, I notice that there are 2 console backends now: xenconsoled seems 
to only watch for the initial console, while a per-domain qemu process is used 
for all subsequent consoles, so any enhancements to the dom0 end would have to 
go into qemu?

So to implement channels via consoles I would need to:

1. check if qemu when acting as a console server in dom0 is able to connect the 
console to a suitably named Unix domain socket in dom0 (signalled via xenstore 
in the usual way)

2. modify libxl to support consoles as configurable devices alongside disks, 
nics etc

3. add support to libvirt’s libxl driver

4. see if I can write something like a udev rule in the guest to notice the 
console, look up the ‘name’ from xenstore and make a suitably-named file?

What do you think?

Cheers,
Dave


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel