Re: [libvirt] [PATCH RFC] Add support for QEMU vhost-user feature

On 05/28/2014 11:46 AM, Luke Gorrie wrote: Daniel has already pointed out that you need to supply a patch to update formatdomain.html.in to document this new interface type. I would also recommend a single simple example of the new <interface> type in the commit log, just to make it easy for someone looking for something in the git log (others may disagree with this - anyone?) So, lacking an example, I deduce from the XML schema and code that it would be something like this: <interface type='vhostuser'> <model type='virtio'/> <socket path='xyzzy' mode='server'/> ... </interface> However, the standard for other interface types is: <interface type='blah'> <model type='virtio'/> <source [attributes describing connection to outside world]/> ... </interface> so it would follow precedent much more closely if you did this: <interface type='vhostuser'> <model type='virtio'/> <source path='xyzzy' mode='server'/> ... </interface> 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> This way we would already have a type to set in the virDomainChrSourceDef object before calling virDomainChrSourceDefParseXML(). (we would just have to do some post-processing to make sure that we emit a reasonable error for any ChrSourceDef type that isn't supported by qemu's vhostuser device, and likewise if someone specified one of those types and forgot the "<driver name='vhost'/>"). Finally, it would be very nice to also define libvirt networks with <forward mode="vhostuser"> (or to follow what I said in the previous paragraph: <forward mode='socket'>, with the info for the source contained in attributes/subelements of the <forward> (similar to what has been done for <forward mode='bridge|private|passthrough|hostdev'). This way the specifics of the network connection aren't hardcoded into the domain definitions, and can be changed for all domains by changing them in a single place; also this could make it possible to live migrate from one host that doesn't support vhostuser onto another host that does (and take advantage of this new capability). (I can see one departure here from what is done with tap-based network types though - in their case the <driver name='vhost'/> is specified in the domain's <interface>, *not* in the network, so it is possible to have some domains that use vhost-net and some that don't. In the case of vhostuser, that doesn't really make sense (maybe it shouldn't be done that was for vhost-net either, but that's a separate issue). I was going to say that it seems odd to make this optional in the schmema when it really is required in practice, but then I saw that the schemas for all the existing interface types do exactly the same thing...