[libvirt] Using vmchannel?

[Gleb Natapov]

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.