On 01/07/2011 10:55 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,
On 01/05/2011 05:19 AM, Daniel P. Berrange wrote: 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
On Wed, Jan 05, 2011 at 09:57:42AM -0500, Laine Stump wrote: 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).