[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 09/05/13 14:13, Konrad Rzeszutek Wilk wrote:
On Thu, May 09, 2013 at 10:09:18AM +0100, George Dunlap wrote:
On 08/05/13 23:39, Konrad Rzeszutek Wilk wrote:
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
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

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
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).
I tend to agree with this; I hate it when some piece of software
tells me, "I'm not going to let you do this for your own good." When
that happens to me, it's almost always the case that I *do* have a
good reason for doing so that the author of the software didn't
think about.  Our users are sysadmins; we should allow them to shoot
themselves in the foot if they want to.

So I think the right thing to do long-term is to make it possible to
do in xl.  Having a "seatbelt" restriction by default that can be
overridden would be OK with me, but I think a warning message when
vcpus > pcpus would suffice.  (We do occasionally see people show up
who don't realize that in the vast majority of cases, vcpus > pcpus
is a stupid way to run things.)

Having a "seatbelt" which is off by default is pretty useless; as
anyone that knows to turn it on almost surely doesn't need it.

My argument was that for the 4.3 release, the potential use cases of
vcpus > pcpus are basically of 0 value as far as I'm concerned; it's
not worth introducing a risk of regression, no matter how small, in
order to allow the "vcpu overcommit" scenario to work.

But as IanJ says:
1. You can already do "vcpu overcommit" by setting things in the config file
2. This fixes a bug when you are running vcpu-set

Fixing a bug *is* worth the tiny amount of risk this represents; so
probably is making the interface consistent.
OK, I am bit lost here. You and Ian seem to have different viewpoints of
what is the right way, or perhaps more likely is that I am misreading
it. The interface consistent in my reading sounds like you are agreeing
that the "I am not going to let you do this for your own good" is silly.

Yes, I think IanC and I are disagreeing about ideal xl behavior. We both agree that "vcpus > pcpus" is a bad configuration. I think ideally we should support it (because administrators should be allowed to shoot themselves in the foot) and Ian seems to be making the case that we shouldn't support it.

But I think IanC and I also both agree that, "This patch enables vcpus > pcpus" is not a good argument to accept any patch at this point in the release cycle.

I think what you and Ian would like me to do:

For Xen 4.3:
  - Add a warning to the vcpu-set that the user might be doing something
    silly if they are trying to set 'xl vcpu-set vcpus' where vcpus >
    pcpus. Something along: "You are overcommiting. You have x PCPUs and
    you want y vCPUS. Aborting - if you would like to do this please use
  - If user is trying to do vcpu-set on more than pcpus abort the request
    unless the '--no-seatbelt' option is provided.

For Xen 4.4:
  - Remove those two things above and make vcpu-set work irregardless of
    the pcpus value? No that does not sound right.

I think for 4.3, if this patch is the quickest way to get rid of the bug of xl crashing, we should just accept it.

Then for 4.4, we can discuss warnings or "seatbelt" options.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.