6:15 a.m.
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.
[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).
[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.
Thoughts?
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
6:29 a.m.
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
AFAIK this support is not yet merged in upstream QEMU and the syntax
is still being debated. It'll be something along these lines, a hybrid
of the -net and -serial syntaxes - the -net bit relating to the guest
device config, and the -serial bit relating the host side config which
is hooked into char devices. It has already gone through 3 completely
different schemes, so until it is merged in QEMU I'd be wary of committing
to support it in libvirt.
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.
I don't think this should be overloading the 'interface' XML format,
rather re-use the character device syntax which will allow full range
of host side configs rather than restricting to UNIX domain sockets.
http://libvirt.org/formatdomain.html#elementsConsole
eg, we have 'console', 'serial', 'parallel' and
'vmchannel' all with
a common set of child elements - the target port conveniently maps
to the VMchannel port number
<vmchannel type='unix'>
<source mode="bind" path="/tmp/foo"/>
<target port="600"/>
</serial>
As an example of using of a non-UNIX domain socket option, consider a
syslog server in guest configured to log via a vmchannel port 700
<vmchannel type='file'>
<source path="/var/log/vm/vm-serial.log"/>
<target port="1"/>
</vmchannel>
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>
A rather scary config until we get fine grained mandatory access control
on the public API calls :-) NB, currently this wouldn't work in most
systems because this will cause it to try to do PolicyKit auth on the
client and be denied since the client isn't in the desktop session.
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.
I don't see that as a problem for libvirt itself since we're not the ones
who want to use it - we're merely providing the mechanism. So i've no
problem adding vmchannel support to libvirt even if its only impl for
QEMU/KVM. If applications/users of it find that they really badly need it
for Xen too, then someone will step up to impl it.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
6:50 a.m.
On Mon, 2009-01-19 at 12:15 +0000, Richard W.M. Jones wrote:
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.
AFAIK, this doesn't require virtio - it's just a NIC, so could be e.g.
e1000 or rtl8139 or virtio_net.
(That could change yet ... but I think that's the current status)
Cheers,
Mark.
6:54 a.m.
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.
5787
days inactive
5787
days old
3 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Gleb Natapov -
Mark McLoughlin -
Richard W.M. Jones