Re: [PATCH 1/2] xl: neuter vcpu-set --ignore-host.

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

> >  - The user can already boot a massively overcommitted guest by
> >    having a large 'vcpus=' value in the guest config and we allow
> >    that.
> 
> IMHO this is an xl bug, I'd be happy to see a patch to fix this and
> require and override here too.

I actually think that doing vCPU overcommit is an OK process. If you go
down the path of 'don't do this b/c it can cause performance degredation'
you might end up with tons of things that we should be turning off:
 - don't use file but use phy for block.
 - if you have 40GB SR-IOV, use that instead of vif.
 - booting PV? You should be booting it in HVM mode on latest machines.
 - etc.

They are all in some cases subjective and the user can have a legitimate
reason to do this instead of using one we think is better.

I want the user to be able to make that choice without constraining
them. This is open source after all - we lift the barriers, not put them
in.
> 
> > 
> > Since we were close to the release we added --ignore-host parameter
> > as a mechanism for a user to still set more vCPUs that the physical
> > machine as a stop-gate.
> > 
> > This patch keeps said option but neuters the check so that we
> > can overcommit. In other words - by default the user is
> > allowed to set as many vCPUs as they would like.
> 
> and why would a naive user want to do this? non-naive users can use the
> option if this is what they really want, and are probably grateful for
> the catch if they didn't intend to overcommit, which is almost always
> even for expert users.

I think adding the WARNING is a good idea (which is how it does it
right now). But this is the similar as running a guest on a NUMA machine
without putting it in proper NUMA containers - we should WARN, not just
outright stop the guest.
> 
> This change need far better rationalisation than "because xend did it"
> and "because we can". IMHO.

>From my non-technical view (and I am not sure if I had made this clear)
there is a lot of users that use 'xend' and want to switch to 'xl'. As such
to make this backwards compatible, even bugs have be considered. Perhaps
another way to do this is to have a global flag - 'xend_compatible' where
even things that are bugs are expected to work certain ways.

I do get your frustration - why would a normal user want to shoot themselves
in the foot with VCPU over-subscription? I have some faint clue - but I
do to get a stream of requests from customers demanding it. And if they pay to
shoot themselves in the foot - well, here is a cocked gun and let me point the
gun at your foot and you can pull the trigger.

Lastly, now that the PV ticketlocks are in and they work for both PV and
HVM I am curious how many people are going to start using it.


Sorry about the long twisted answer - I hope this will get the discussion a bit
more going forward so we can decide what we want to do for Xen 4.4.