[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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!




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]