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. -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list