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:
> 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.


> 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