[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 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
> >>>>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).
> 
> 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.

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
   --no-seatbelt'.
 - 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.

<goes off to get some coffee>


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


 


Rackspace

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