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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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.

>   - 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