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

[Laine Stump]

On 05/28/2014 11:46 AM, Luke Gorrie wrote:
> vhost-user is a networking backend based on unix domain sockets
> instead of tap devices and ioctl(). This makes it possible for
> userspace networking stacks (vswitches) to provide vhost-networking to
> guests.
>
> Signed-off-by: Luke Gorrie <luke at snabb.co>
> ---
>  docs/schemas/domaincommon.rng                      | 23 ++++++++
>  src/conf/domain_conf.c                             | 42 ++++++++++++++
>  src/conf/domain_conf.h                             |  5 ++
>  src/lxc/lxc_process.c                              |  1 +
>  src/qemu/qemu_command.c                            | 66 +++++++++++++++++++++-
>  src/uml/uml_conf.c                                 |  5 ++
>  src/xenxs/xen_sxpr.c                               |  1 +
>  tests/qemuxml2argvdata/qemuxml2argv-hugepages.args |  2 +-
>  8 files changed, 142 insertions(+), 3 deletions(-)

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).


>
> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
> index af67123..30e7daf 100644
> --- a/docs/schemas/domaincommon.rng
> +++ b/docs/schemas/domaincommon.rng
> @@ -1966,6 +1966,29 @@
>              <ref name="interface-options"/>
>            </interleave>
>          </group>
> +        <!-- vhostuser interface: specify unix socket path, socket mode -->
> +        <group>
> +          <attribute name="type">
> +            <value>vhostuser</value>
> +          </attribute>
> +          <interleave>
> +            <optional>

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