[libvirt] RFC: exposing a config setting to force vhost-net support on/off

[Laine Stump]

There's a request to allow libvirt to explicitly turn on/off the new 
vhost-net feature of virtio network cards. I see a few ways to do it, 
and am looking for opinions on which is best.

(For the uninitiated, vhost-net is a new kernel-based virtio 
implementation that saves the overhead of having all network traffic be 
handled by the userlevel qemu process.)

The original implementation of vhost-net support (what's been in libvirt 
for a few releases now) doesn't expose any knobs to the user - if the 
vhost-net kernel module is loaded, libvirt uses it for all virtio 
network devices of all newly created guests, and if the kernel module 
isn't loaded, it reverts to using the old user-level virtio.

It's simple enough to put a bit of extra logic at the point where we 
make that decision. I see 3 possibilities:

1) default - use vhost-net if it's loaded, don't if it isn't (current 
behavior)

2) require - use vhost-net if it's loaded, and refuse to start the guest 
if it isn't (for those who want
    to be 100% sure they're using it)

3) disable - don't use vhost-net, whether or not it's loaded (to disable 
it, eg in case a compatibility problem
    is found between vhost-net and some particular guest)

The question is how to describe that in the XML. Here's what a virtio 
network interface might look like currently:

   <devices>
     <interface type='network'>
       <source network='default'/>
       <model type='virtio'/>
     </interface>
   </devices>


1) One possibility (the simplest) would be to add an optional attribute 
to <model>:

   <devices>
     <interface type='network'>
       <source network='default'/>
       <model type='virtio' vhost='default|require|disable'/>  (or 'default|on|off' ?)
     </interface>
   </devices>

or maybe:

   <devices>
     <interface type='network'>
       <source network='default'/>
       <model type='virtio' mode='default|kernel|user'/>
     </interface>
   </devices>


2) Another possibility would be to define a new sub-element of<interface>, called "<driver>", similar
    to what's done in the storage device XML. In the future, other backend driver-related items could be placed there:

   <devices>
     <interface type='network'>
       <source network='default'/>
       <model type='virtio'/>
       <driver vhost='default|require|disable'/>   (or "mode='default|kernel|user'")
     </interface>
   </devices>

3) A third method, which might make the XML file look less ugly if, in the future, there were *many*
    more configurable items for interface backends (this one was inspired by the<memtune>  element):

   <devices>
     <interface type='network'>
       <source network='default'/>
       <model type='virtio'/>
       <driver>
         <vhost>default|require|disable</vhost>
       </driver>
    </interface>
   </devices>


(we *might* want to consider naming it something other than "<driver>", eg"<tune>" or something like that, so that
more things could be put in there. The problem with that is I don't really consider vhost a true "tunable", since
as far as I'm aware, it's always faster to use kernel-level virtio than to bounce everything up to userspace; the
setting in question is intended more for testing purposes, or to alleviate unforeseen compatibility problems).


So, any opinions on these three possibilities (or an undescribed 4th?) What about the naming? I'm open to suggestions!