Re: RFC: exposing a config setting to force vhost-net support on/off

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

 



On 01/04/2011 12:37 PM, Laine Stump wrote:
> 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)

I agree with these three modes.

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

Lumping it all as attributes of <driver> makes the most sense to me,
given the similarity to the comparable number of attributes under
<disk>/<driver> (name, type, cache, error_policy; and the current talk
of adding another attribute for qemu aio policy).

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

So count my vote for option 2 for where to stick the choice.  As for the
option names, my preference is in this order:

mode=default|kernel|user - either way, there is some virtio going on,
but this makes it clear when a kernel module is needed, leaving the name
'vhost' out of the picture (since it is merely an implementation detail
of how the kernel provides virtio)

vhost=default|require|disable - makes it clear that we are requiring
vhost support, but the use of a kernel module becomes implicit (you have
to know that vhost implies kernel)

vhost=default|on|off - shorter names, but creates confusion (vhost=on
means the guest will fail to start if vhost is _off_ in the kernel).

But I'm not hard-set on my choice for option 2 out of the 3, or for the
option naming of default|kernel|user, so feel free to use a different
option if you get votes in a different direction.

-- 
Eric Blake   eblake@xxxxxxxxxx    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]