[libvirt] libvirt, libxl and <channels>

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