On Thu, Jun 05, 2014 at 05:09:02PM +0300, Laine Stump wrote:
Daniel pointed out that qemu actually accepts any generic character
device to connect to, and it makes sense to support this by using
virDomainChrSourceDefPtr. However, the parse function for
virDomainChrSourceDef requires that the type of character device be
already parsed and set in the object, implying that it needs to be in
the config somewhere outside of the <source> element itself.
Related to that, I'm wondering if maybe instead of setting the type of
<interface> to the very specific "vhostuser", maybe it could be set to
the type of character device ("socket", "tcp", etc), and the fact
that
vhostuser is used could be specified in exactly the same way that
vhost-net is turned on for tap devices - with <driver name="vhost"/>. So
for example, you would have this:
<interface type='unix'> <!-- for a unix domain socket -->
<model type='virtio'/>
<driver name='vhost'/>
<source path='xyzzy' mode='server'/>
...
</interface>
The problem with this is that some of the chardev 'type' options
clash with some of the interface 'type' options, so I think we
must keep them separated. I do agree that 'vhostuser' is a somewhat
QEMU specific name - at least with 'tap' this was a common terminology
across multiple OS and projects. This is really a variant on 'tap'
which is avoiding use of kernel devices. To perhaps we should call
this new mode 'usertap' ? Or another idea would be to call it 'tapstream'
eg
<interface type='usertap'>
<model type='virtio'/>
<driver name='vhost'/>
<source type='unix'>
...chardev source schema...
</source>
</interface>
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|