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