From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH] libxl: Make 'xl vcpu-set' work properly on overcommited hosts. Date: Thu, 9 May 2013 09:13:49 -0400 Message-ID: <20130509131349.GC7945@konrad-lan.dumpdata.com> References: <1368009999.26321.223.camel@zakaz.uk.xensource.com> <20130508142903.GA9314@phenom.dumpdata.com> <1368025493.17285.18.camel@zakaz.uk.xensource.com> <20130508163550.GC369@phenom.dumpdata.com> <1368031774.17285.49.camel@zakaz.uk.xensource.com> <20130508170515.GA1184@phenom.dumpdata.com> <1368040183.3756.17.camel@dagon.hellion.org.uk> <20130508223911.GA9226@phenom.dumpdata.com> <518B67BE.2000703@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <518B67BE.2000703@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: "juergen.gross@ts.fujitsu.com" , "xen-devel@lists.xensource.com" , Ian Jackson , Ian Campbell List-Id: xen-devel@lists.xenproject.org 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.