On Mon, Jan 19, 2009 at 12:15:14PM +0000, Richard W.M. Jones wrote:
I was just looking at the new vmchannel feature in QEMU and was wondering if we could make this available in libvirt.
Firstly, since there isn't much documentation, I should explain how vmchannel works:
[1] You pass an extra parameter on the qemu command line:
qemu [...] -vmchannel <port>:<dev>
where <port> is the TCP port number (see below) and <dev> is a standard qemu device description. As an example:
qemu [...] -vmchannel 600:unix:/some/path
[2] A new character device appears in the host, eg. Unix domain socket called "/some/path".
[3] In the host, a userspace program should open a socket, bind(2) it to /some/path and listen(2) and accept(2) on it.
unix:/some/path is just an example. It is possible to specify any qemu character device there with the same syntax as -serial option. So, for instance, you can specify unix:/some/path,server,nowait and then the host userspace program will need to use connect(2) only and qemu will do the server part.
[4] In the guest, any process may connect(2) to TCP 10.0.2.4:600 (or whatever port was selected). Each connection in the guest causes the listener in the host to accept(2).
Only one process can connect(2) to one vmchannel port. This restriction comes from the fact that only one process on the host can connect to qemu character device.
[5] This is only designed for low-bandwidth, low-performance applications.
[6] Multiple vmchannels are supported.
[7] Host cannot initiate a connection.
My plan to implement this would be to add a new network interface type to the domain XML:
<interface type='vmchannel'> <source port='600'/> <target path='/some/path'/> </interface>
Only Unix domain socket paths would be allowed on the host side, and the path would be expected to exist already with suitable permissions.
Note that I think this would also allow guests to communicate with the libvirtd on the host (not by default, of course, but if users wanted to configure it that way), for example:
<interface type='vmchannel'> <source port='600'/> <target path='/var/run/libvirt/libvirt-sock'/> </interface>
One problem is that it is qemu/kvm-only. It is built on top of virtio, and virtio is meant to become a standard driver subsystem for all full virtualization systems.
virtio is not required to use vmchannel. This is not final, but I hope it stays this way. -- Gleb.