Re: [Xen-devel] [PATCH 2/2] expert_mode: Add a new configuration option for expert users.

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-07-17 at 12:03 +0100, George Dunlap wrote:
> On 17/07/13 11:56, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH 2/2] expert_mode: Add a new 
> > configuration option for expert users."):
> >> On Fri, 2013-07-12 at 14:08 -0400, Konrad Rzeszutek Wilk wrote:
> >>> This could also be called 'seatbelt' option.
> >>>
> >>> libxl has a variety of checks where it will fail out an operation
> >>> unless the user has provided an --force (or --ignore) parameter.
> >>> Currently one such check is for the 'vcpu-set' command which
> >>> will error out if the count of virtual cpus is greater than the
> >>> physical cpus. This parameter will ignore such checks and allow
> >>> the user to do the operations without the need for override flags.
> >> Does this overlap  somewhat with various commands which individually
> >> take a -f(orce) option?
> > Clearly it should disable all of those -f's too.
> >
> >>> +=item B<expert_mode=BOOLEAN>
> >>> +
> >>> +Do not act on host performed checks that might lead to performance
> >>> +degradations. Currently checks are made for following operations:
> >>> + - C<vcpu-set> - if the number of VCPUs set for a guest is higher than 
> >>> the
> >>> +   physical count the operation will error out.
> > I don't think this is a very coherent specification.  Surely it should
> > override "all -f options" or something similar.
> 
> I think that makes sense for some but not all.  For example, for "xl 
> shutdown", -f means "send an ACPI event if no PV drivers are detected".  
> I don't think we'd want to change that behavior with such a switch.  
> (Arguably -f was the wrong option to use for that in the first place, 
> but it's a bit late for that now.)

That's -F (for fallback not force), deliberately avoiding -f for the
reasons you might think.

If "xl shutdown -f" were to do anything it would probably be to act as
"xl destroy" (nb I don't think we should actually do that...)

Ian.


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