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

[George Dunlap <george.dunlap@eu.citrix.com>]

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.

  -George