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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-09-26 at 17:01 +0100, Andrew Cooper wrote:
> On 26/09/13 16:47, Ian Campbell wrote:
> > On Thu, 2013-09-26 at 11:28 -0400, Konrad Rzeszutek Wilk wrote:
> >>>>  - 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.
> > Those are all legitimate choices for a user to make. 
> >
> > Overcommitting VCPUs is not.
> 
> Depends how the overcommitting happens.  What about:
> 
> * User creating N VMs which are individually undercomitted but has the
> same effect as creating 1 VM which is stupidly overcommitted.

That's a different, and legitimate, case.

The case here is creating a single VM which has more VCPUS and PCPUS.

> * Power management decides to shut down some of the PCPUs because it can
> service all the current VCPUs from some somewhat idle domains on fewer PCPUs

Hopefully these checks are based on the actual total and not the
artificially lowered limit. If not then that would be bug.

> While I agree that creating a single VM which is overcommitted in terms
> of VCPUs is either a user error or power-user, that alone is not a
> justification for it being impossible/very hard to do.

It's not even as obscure as "very hard", there is a simple CLI option to
allow it!

Ian.


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