Re: [RFC PATCH 1/3] xl: replace vcpu-set --ignore-host with --ignore-warn

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

On Tue, Jul 23, 2013 at 06:52:44PM +0100, George Dunlap wrote:
> On 07/23/2013 03:01 PM, Konrad Rzeszutek Wilk wrote:
> >On Tue, Jul 23, 2013 at 12:29:36AM +0100, George Dunlap wrote:
> >>On 07/19/2013 04:48 PM, Konrad Rzeszutek Wilk wrote:
> >>>When Xen 4.3 was released we had a discussion whether we should
> >>>allow the vcpu-set command to allow the user to set more than
> >>>physical CPUs for a guest. The author brought up:
> >>>  - Xend used to do it,
> >>>  - If a user wants to do it, let them do it,
> >>>  - The original author of the change did not realize the
> >>>    side-effect his patch caused this and had no intention of changing it.
> >>>  - The user can already boot a massively overcommitted guest by
> >>>    having a large 'vcpus=' value in the guest config and we allow
> >>>    that.
> >>>
> >>>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 removes said option and adds the --ignore-warn option.
> >>>By default the user is allowed to set as many vCPUs as they would like.
> >>>We will print out a warning if the value is higher than the physical
> >>>CPU count. The --ignore-warn will silence said warning.
> >>
> >>I think this is a good change in general, but I don't think the name
> >>is quite right.  You're not ignoring the warnings, you're turning
> >>them off.  Maybe make the function argument "warn", and the option
> >>"--no-warn"?
> >
> >--silence?
> 
> Well there is some --quiet, but I suppose that generally means don't
> tell me *anything*, which is not what we want either.  I would think
> --silence would mean about the same thing.

Good point. In which case I think --no-warn and no short option
makes the most sense.

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