Re: [Xen-devel] [PATCH 32 of 32 RFC] libxl: Default to stub device model whenever possible

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 16 Jan 2012, Ian Campbell wrote:
> > > > Considering that stubdoms are not yet at feature parity I don't think we
> > > > should make this change for 4.2.
> > > > At the very least we should expand the set of conditions on which we 
> > > > base
> > > > the decision on: certainly the presence of an audio device, maybe pci
> > > > passthrough and the type of block backend (considering that some of them
> > > > go through qemu now) in case they aren't working properly.
> > > 
> > > Tweaking the precise conditions is reasonable and indeed the main thrust
> > > of the series is to allow to make this sort of determination and to
> > > change our minds about it.
> > 
> > The danger of this approach is that stubdoms are not really transparent
> > from the admin point of view.
> > From the basic difference when you "xl list", to memory usage, a stubdom
> > based setup is quite different from a non-stubdom based setup.
> > If I were an admin I would really want to know when I am running one or
> > the other.
> 
> > Making the change under their feet is bad enough but making a difference
> > choice depending on a various set of variables is certainly not going to
> > be popular.
> 
> Our recommendation as upstream is that stub domains are the most
> scalable and secure configuration. I think our defaults should reflect
> that.
> 
> Users who care specifically about stubdom or not can continue to force
> the choice (using device_model_stubdomain_override=1|0 in their config).

While the benefits of stubdoms in terms of security are a no brainer,
the benefits in terms of scalability are certainly less clear: are we
actually sure that using stubdoms is more scalable than a 64 bit dom0
with multiple vcpus?
I am asking because qemu instances running on Linux would share text and
use only the ram they actually need (nowadays most VMs have PV drivers
anyway) while stubdoms would unconditionally take 32MB of ram.
I don't think anybody actually run any real world benchmarks to
demonstrate any scalability benefits. Before saying that they are our
recommended solution and before switching them to default maybe we ought
to run at least one?
Otherwise if these tests have been run, I would like a link to some
nice figures :)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel