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 :|