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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2012-01-16 at 17:01 +0000, Stefano Stabellini wrote:
> On Mon, 16 Jan 2012, Ian Campbell wrote:
> > On Mon, 2012-01-16 at 15:53 +0000, Stefano Stabellini wrote:
> > > On Mon, 16 Jan 2012, Ian Campbell wrote:
> > > > # HG changeset patch
> > > > # User Ian Campbell <ian.campbell@xxxxxxxxxx>
> > > > # Date 1326715929 0
> > > > # Node ID 953a1ce643856edcf9fbbbc2680690b3a26dede8
> > > > # Parent  a2dc899d0f229d82baca92a06b3b7a5b4d918324
> > > > libxl: Default to stub device model whenever possible.
> > > 
> > > 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).

Ian.
> 
> 
> > Disabling stub-dm in the face of an audio is a no brainer. PCI
> > passthrough less obviously so since itm in theory, works but given the
> > number of problems we've had with it I'm inclined to also gate on that.
> > 
> > Which leaves block devices which is an interesting one because currently
> > I don't have enough info in hand during
> > libxl__domain_build_info_setdefaults to make that determination. I shall
> > look at how I can resolve that.
> 
> Theoretically this case could also work with stubdoms because the block
> backend would be provided by the other qemu, the one running in dom0.
> However it is not probably going to work right now.



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