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

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Thursday, October 25, 2012, 5:56:00 PM, you wrote:

> Ian Campbell writes ("Re: [PATCH 0 of 5] xl shutdown compatibility with xm"):
>> ACPI fallback != shutdown. It might just as likely be a hibernate or
>> (more likely) a reboot.
>> 
>> Are we going to add code to xl which forces on_reboot = destroy when xl
>> shutdown -F is invoked on a domain?

> We might need to do something along those lines.

>> > But i try to explain that for this special case it doesn't matter if
>> > xl shutdown tries to do the acpi fallback automatically, since this
>> > admin shouldn't use xl shutdown on this domain anyway.
>> 
>> Whether they should or not the xendomains script is going to magically
>> do it for them.

> Well, at the moment the xendomains script will try "xl shutdown" and
> if that fails the guest will be shot in the head.  Trying the acpi
> fallback is surely better?

Perhaps it helps to keep the 2 "use cases", 2 possible changes and their 
arguments apart:
1) xl shutdown invoked by the xendomains init script
2) xl shutdown invoked manually by a admin or admin-scripts

Possible variants:
Change A) Only change the xendomains init/sysconfig script, and add the -F 
option to the command.
  Or
Change B) Change the xl shutdown command and remove the -F option, always try 
acpi fallback when pv fails.





1) xl shutdown invoked by the xendomains init script (also used in a non 
machine shutdown scenario)
   At present:
               - a guest which can handle the pv shutdown:                      
               Guest will shutdown properly.
               - a guest which can't handle pv but would do *shutdown* on the 
acpi fallback:   Xl shutdown will fail, guest will be shot through the head on 
hardware shutdown.
               - a guest which can't handle pv but would do *something* on the 
acpi fallback:  Xl shutdown will fail, guest will be shot through the head on 
hardware shutdown.
               - a guest which can't handle pv and does nothing on acpi 
fallback:              Xl shutdown will fail, guest will be shot through the 
head on hardware shutdown.

               So at present if the domain doesn't react to pv it will be shot 
through the head anyway, so it could eat your data at present as well, (but in 
my case i seem to
               be testing and relying on journalling filesystems for some time) 
:-)

    After change (both A or B):
               - a guest which can handle the pv shutdown:                      
               Guest will shutdown properly.
               - a guest which can't handle pv but would do *shutdown* on the 
acpi fallback:   Guest will shutdown properly.
               - a guest which can't handle pv but would do *something* on the 
acpi fallback:  Xl shutdown will fail, guest will do *somehting* AND be shot 
through the head on hardware shutdown.
               - a guest which can't handle pv and does nothing on acpi 
fallback:              Xl shutdown will fail, guest will be shot through the 
head on hardware shutdown.

    So both change A or B seem to have no serious negative side effects unless 
the acpi fallback triggers something like a "rm -rf /" in the guest.
    Such disastrous behavior seems unlikely, but if present, it would probably 
be known to the admin. In that case he should take special care of this guest 
anyway.

    It does make a guest that supports properly shutting down on acpi power 
button to do just that, so in my opinion both change A or B would be a win in 
this use case.


2)  xl shutdown invoked manually by a admin or admin-scripts (also used in a 
non machine shutdown scenario)
    At present:
               - a guest which can handle the pv shutdown:                      
               Guest will shutdown properly.
               - a guest which can't handle pv but would do *shutdown* on the 
acpi fallback:   Xl shutdown will fail, admin can supply -F after which the 
guest will shutdown properly.
               - a guest which can't handle pv but would do *something* on the 
acpi fallback:  Xl shutdown will fail, admin can supply -F after which the 
guest will do *something* but doesn't shutdown.
               - a guest which can't handle pv and does nothing on acpi 
fallback:              Xl shutdown will fail, guest will do nothing and doesn't 
shutdown.

    After change (A)):
               - Same as present

    After change (B)):
               - a guest which can handle the pv shutdown:                      
               Guest will shutdown properly.
               - a guest which can't handle pv but would do *shutdown* on the 
acpi fallback:   Guest will shutdown properly.
               - a guest which can't handle pv but would do *something* on the 
acpi fallback:  Guest will do *something* but doesn't shutdown.
               - a guest which can't handle pv and does nothing on acpi 
fallback:              Xl shutdown will fail, guest will do nothing and doesn't 
shutdown.

               In this case the win is for the guests that support shutdown on 
the acpi fallback, it removes the need for a user intervention and supplying 
the -F option.
               The downside would be a admin using xl shutdown on a domain that 
does *something* on acpi fallback, where *something* is some devastating action.
               This seems unlikely, but if present, it would probably be known 
to the admin. In that case he shouldn't use xl shutdown, and probably won't use 
it anyway since it won't help him anyway.

Summary:

               - change (A) looks quite uncontroversial to me
               - change (B) has as additional benefit that it's one option and 
manual intervention less to care about (especially for scripts, since it's 
quite possible to forget the -F option there (see IanJ with the test harness 
scripts)

--
Sander

> Ian.



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