Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Tuesday, October 16, 2012, 11:43:20 AM, you wrote:

> On Tue, 2012-10-16 at 09:59 +0100, Sander Eikelenboom wrote:
>> Monday, October 15, 2012, 1:45:33 PM, you wrote:
>> 
>> > On Mon, 2012-10-15 at 12:21 +0100, Sander Eikelenboom wrote:
>> >> Monday, October 15, 2012, 12:37:57 PM, you wrote:
>> >> 
>> >> > On Mon, 2012-10-15 at 11:32 +0100, Sander Eikelenboom wrote:
>> >> >> Hi Ian,
>> >> >> 
>> >> >> Great thanks !
>> >> >> Only thing i was wondering about:
>> >> >> 
>> >> >> Shouldn't the "-F" option be dropped in favour of always trying the
>> >> >> "acpi fallback" when the pv shutdown fails.
>> >> >> 
>> >> >> This because the shutdown scripts still don't work for domains without
>> >> >> pv shutdown and i don't see a down side to just trying that as
>> >> >> fallback.
>> >> 
>> >> > It is guess OS dependent what the ACPI button press event does, it can
>> >> > reboot, shutdown or hibernate etc depending on the OS type and its
>> >> > configuration. (in theory I suppose it is completely arbitrary e.g. it
>> >> > could be configured to eject the CD-ROM or something equally random).
>> >> 
>> >> > Therefore the user needs to be aware of when they can safely use it.
>> >> 
>> >> Well yes and no:
>> >>     - can't remember having (to make) that choice with xm ?
>> 
>> > Looks like xend uses SCHEDOP_remote_shutdown. It's unclear to me why
>> > this is better than just shooting the domain with destroy...
>> 
>> >>     - On shutdown with xl as toolstack and when the guest doesn't
>> >> support pv shutdown, the init.d/xendomains script doesn't even attempt
>> >> to shutdown this guest by acpi fallback.
>> >>     - As a result when using xl as toolstack, the guest is terminated
>> >> non gracefully when the whole machine finally shutsdown, which seems
>> >> less desirable then at least *trying* to shut it down gracefully by
>> >> using the acpi button.
>> 
>> > Using the ACPI fallback is a decision which can only be made locally
>> > with full knowledge of the configuration of the guests.
>> 
>> I'm not totally convinced (yet):
>>   - In case of a system shutdown, it seems better to at least *try* instead 
>> of just halting the system without shutting such a guest down.

> You might as well do xl shutdown, wait a bit, xl destroy in the
> initscript. "xm shutdown" is effectively "xm destroy" for guests without
> PV drivers.

>>       For the shutdown scripts the problems is that there is no way to give 
>> it the "full knowledge" of how to shutdown a particular guest.
>>       It would be possible to use the -F flag in the sysconfig xendomains 
>> file, since the pv shutdown is always tried first.

> It would be possible for an individual administrator to add -F if that
> is compatible with their configuration. It would be inappropriate for
> upstream to do this by default because we *don't know* what -F does to
> an arbitrary guest.

It's just that i think upstream should use sensible defaults that work in the 
majority of cases (unless it will have a devastating effect in de minority of 
cases).
In this case both hvm guests with fairly old windows and linux install seem to 
respond correctly to the acpi powerbutton, so perhaps the majority of cases.
In the minority of cases it will perhaps do something else, but could/will that 
really be more devastating than the pulling the rug from under a guests feet 
when the machine powers down without the guest being shutdown ?

But any how, since it's not acceptable to upstream i will keep it in my private 
scripts and shut up :-)


>>   - Not everyone seems to be aware, say an IanJ ;-)
>>       Under the assumption that the guests in the xen-test-harness do react 
>> in the right way to a acpi powerbutton event,
>>       it seems the "never passes" in  "Guest-stop" row of 
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/13967/
>>       Will probably pass when the -F option will be used, see 
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/13967/test-amd64-i386-xl-win7-amd64/13.ts-guest-stop.log

> Ian J is well aware that -F could help here (this is the main reason I
> implemented this option). It would be appropriate here because we can
> control the guest OS configuration in the harness (and if we can't we
> shouldn't use -F).

> He just hasn't implemented it in the harness yet (TBH I suspect he has
> forgotten ;-)).

> Ian.




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