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!
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list