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

[Laine Stump]

On 01/07/2011 10:55 AM, Daniel P. Berrange wrote:
> On Wed, Jan 05, 2011 at 09:57:42AM -0500, Laine Stump wrote:
>> On 01/05/2011 05:19 AM, Daniel P. Berrange wrote:
>>> We should try to keep terminology matching the disk<driver>
>>> so I think
>>>
>>>    <driver name='qemu|vhost'/>
>>>
>>> with omission of<driver>   resulting in us automatically
>>> adding either 'qemu' or 'vhost' to the XML. We don't
>>> want to have an explicit 'default' value in the XML,
>>> because users should be able to see the guest is running
>>> with.
>> Do you mean to add it to the XML that's saved in the config? If so,
>> that would mean that it would only be possible to configure it as
>> "use whatever is best for the current situation" for the first
>> startup of the domain. Once that happened, it would be stuck on
>> whichever was used the first time (qemu or vhost), so if the domain
>> was  first started when vhost-net was loaded, then later restarted
>> when vhost-net wasn't loaded (or maybe migrated to another host that
>> didn't have vhost support), it would fail to start.
> Yes, I *did* actually mean to set it in the permanent XML
> config, so once a choice is made, that choice is preserved
> thereafter. This gives us better reliability in the future
> if a further possible 'default' options are introduced and
> we want to avoid existing guests accidentally getting the
> new option for some reason.

And if that auto-selected option isn't possible (esp. if "vhost" is 
selected), should it fail? Or fall back? It seems friendlier to me to 
have a mode that tries to do the best it can with the current situation 
(similar to how it works now without any config).

>> Aside from that, I'd been thinking that the "backend" driver in this
>> case is virtio, not qemu or vhost; qemu(userland) vs vhost seems
>> like just a setting within that driver. So it doesn't seem
>> appropriate to me to have the name decide whether to use userland or
>> vhost.
> Hmm, I thought vhost was a property of any tap device based
> backend, rather than virtio ?

Nope. According to cdub, vhost-net is only for virtio (although he 
points out that macvtap will work with any tap device, which I didn't know).

At any rate, I'm not really comfortable putting this in the "name" attribute

>> One other twist - there's already another request for something else
>> to be set for each network device: sndbuf.
>>
>> <https://bugzilla.redhat.com/show_bug.cgi?id=665293>
>> https://bugzilla.redhat.com/show_bug.cgi?id=665293
>> <https://bugzilla.redhat.com/show_bug.cgi?id=665293>
>>
>> The sndbuf setting is applicable to any network device that connects
>> to the real world using a tap device (ie, not just virtio). If we
>> want to add that setting via the same scheme, we would need
>> something like:
>>
>> <driver name='qemu|vhost' sndbuf='0'/>
>>
>> (0 can't be the default, because 0 is actually one of the settings
>> that they want to explicitly specify (if sndbuf isn't given on the
>> commandline, qemu defaults to 1048576).
> sndbuf is much more like a true "tunable" than vhost is, so
> I think it makes sense to have a generic representation for
> NIC tunables.

Should these tunables be formatted like <memtune>:

   <memtune>
     <hard_limit>1048576</hard_limit>
     <soft_limit>131072</soft_limit>
     <swap_hard_limit>2097152</swap_hard_limit>
     <min_guarantee>65536</min_guarantee>
   </memtune>

?? so something like this?

     <interface type='network'>
       <source network='default'/>
       <model type='virtio'/>
       <tune>
         <sndbuf>0</sndbuf>
         ...
       </tune>
     </interface>

or some other name? Or possibly even forget about the <tune>, and just 
put them all at the top level of <interface> ? (probably not, nesting it 
makes it more obvious what they are).