Re: [Xen-devel] [PATCH] libxl: Make 'xl vcpu-set' work properly on overcommited hosts.

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

> > > > Well, overcommit comes in mind. Say you migrate to a 4PCPU box and you
> > > > have 12VCPUs, then you decide to go down to 4, then back to 16 before
> > > > migrating it to some other box. Can't do.
> > > 
> > > You could do it *after* the migration back to a 16 way box n stead of
> > > before though, which is most likely when you would actually want to do
> > > it...
> > 
> > I am kind of lost. Are we arguing for this being a bug or whether there is
> > justification for putting in Xen 4.3?
> 
> The former needs deciding before the latter.
> 
> I'm not convinced that the current xl behaviour of refusing to
> overcommit VCPUs on a host isn't the right one for the majority of use
> cases. Obviously the silently refusing bit is a bug which should be
> fixed.
> 
> I don't buy that this is a "regression compared to Xend". It's certainly
> a difference from how xend behaved but it seems on the whole to be a
> positive one (i.e. xend was wrong).

CC-ing Juergen here as he added this in.
> 
> Can you explain the use case for wanting to do this? I don't think the
> migration one you give above is very convincing since a normal user
> wouldn't want to overcommit on the source host, they would want to
> migrate and then increase the number of vcpus, without ever
> overcommitting, and therefore without the terrible performance of
> overcommitting.

It seems clear to me if a user wants to over-commit, then we should
allow the user to do so. If we provide a command to set X vCPUs it
should work as described - without the extra checks (unless
that is enabled by some other option).

That is currently not the case and the documentation does not mention
why or why the choice to limit the amount was implemented  - and looking
back at the changeset that introduced this: c/s 22918 (CC Juergen here)
it looks as the original behavior was to do it as Xend does.

If we want a behavior where we don't allow to overcommit (which sounds
bogus - that is part allure of virtualization) then we should also
tweak other 'xl' commands. For example you can do a similar scenario in
which you launch say sixteen 1VCPU guests and you get the same performance
characteristics as if you launch one guest with 16VCPUs on a 4PCPU machine.
Or perhaps worst.

Or say you launch a guest with sixteen VCPUs without trouble right now, but
then if you decrease to one and then want to go back to sixteen it refuses
to do so (without telling you why).

But if tells you why (say by adding a warning that says "You don't want to
overcommit") then the user will ask two questions (I would :-)):
 a) Why didn't xl create complain then initially?
 b) Why can't I overcommit? I want to and this 'xl' is refusing me to do it!
 c) It worked with xend!

> 
> A compromise might be a non-default option to allow users to force
> overcommit but to otherwise deny it.

That can be done. But I would turn it around. Allow it by default and
provide another option (perhaps a default global in /etc/xen/xl.conf)
that will disable overcommiting as much as possible.

And also why don't we want overcommiting?
> 
> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel