Open Stack

http://libvirt.org/formatdomain.html
Lifecycle control

It is sometimes necessary to override the default actions taken when a guest
OS triggers a lifecycle operation. The following collections of elements
allow the actions to be specified. A common use case is to force a reboot to
be treated as a poweroff when doing the initial OS installation. This allows
the VM to be re-configured for the first post-install bootup.

  ...
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  ...

on_poweroffThe content of this element specifies the action to take when the
guest requests a poweroff.on_rebootThe content of this element specifies the
action to take when the guest requests a reboot.on_crashThe content of this
element specifies the action to take when the guest crashes.

Each of these states allow for the same four possible actions.
destroyThe domain will be terminated completely and all resources released
restartThe domain will be terminated, and then restarted with the same
configurationpreserveThe domain will be terminated, and its resource
preserved to allow analysis.rename-restartThe domain will be terminated, and
then restarted with a new name

on_crash supports these additional actions since 0.8.4.
coredump-destroyThe crashed domain's core will be dumped, and then the
domain will be terminated completely and all resources released
coredump-restartThe crashed domain's core will be dumped, and then the
domain will be restarted with the same configuration

On Tue, Jul 5, 2011 at 10:52 AM, Michael Marrotte <marrotte at gmail.com>wrote:

> At least for KVM, I think you can add something like
> <on_poweroff>destroy</on_poweroff> to VM definsiont file...
>
>
> On Tue, Jul 5, 2011 at 8:48 AM, Tom Fifield <fifieldt at unimelb.edu.au>wrote:
>
>> Hi,
>>
>> Thanks again - unfortunately this is similar to what Mike Marrotte wrote
>> in a previous email.
>>
>> Neither Terry (the original author) or myself appear to be in a situation
>> where we want to, or have the ability to modify things happening inside the
>> guest VM :)
>>
>> Regards,
>>
>> Tom
>>
>>
>> On 07/05/2011 10:45 PM, Leandro Reox wrote:
>>
>>> Tom ,
>>>
>>> Just thinking out loud, maybe you can pass out your API credentials via
>>> metadata in boot time, and then use them to :
>>>
>>> - When a user issues "shutdown -h" , is really an alias to post a
>>> "Terminate" to the nova API
>>> - Then the instance "suicides" itself and you get what your users are
>>> expecting :)
>>>
>>> Regards
>>>
>>> Lele
>>>
>>>
>>>
>>> On Tue, Jul 5, 2011 at 9:36 AM, Tom Fifield <fifieldt at unimelb.edu.au
>>> <mailto:fifieldt at unimelb.edu.**au <fifieldt at unimelb.edu.au>>> wrote:
>>>
>>>    Hi,
>>>
>>>    Thanks for your reply!
>>>
>>>    I'm dealing with a lot of users who expect the same style as Amazon,
>>>    which as I mentioned below is that within a guest VM 'shutdown -h
>>>    now' is like saying "I don't want this instance anymore". This is
>>>    the 'terminate' state for guest VMs, hence the cron to clean it up.
>>>
>>>    Good point about recovery from nova-compute host issues though. We
>>>    only want to terminate instances that have been taken down by the
>>>    user, rather than ourselves ;)
>>>
>>>    Regards,
>>>
>>>    Tom
>>>
>>>
>>>    On 07/05/2011 10:29 PM, Leandro Reox wrote:
>>>
>>>        Tom,
>>>
>>>        I dont know if croning the "Terminate" for instances in
>>>        "shutdown" state
>>>        is a good idea, after a Physical node restart the instances
>>>        running in
>>>        that node stays in shutdown mode after the node comes back, you
>>> can
>>>        "re-awake" them by issuing nova reboot, maybe a cleaner an usefull
>>>        script will try to "reboot" the instance and if doest succeed
>>>        terminate
>>>        them, just an idea.
>>>
>>>        Regards
>>>        Lele
>>>
>>>        On Tue, Jul 5, 2011 at 1:50 AM, Tom Fifield
>>>        <fifieldt at unimelb.edu.au <mailto:fifieldt at unimelb.edu.**au<fifieldt at unimelb.edu.au>
>>> >
>>>        <mailto:fifieldt at unimelb.edu._**_au
>>>        <mailto:fifieldt at unimelb.edu.**au <fifieldt at unimelb.edu.au>>>>
>>> wrote:
>>>
>>>        Hi,
>>>
>>>        Echoing this request - it's very handy on Amazon EC2 when a
>>> shutdown
>>>        -h now command results in instance termination.
>>>
>>>        Is there a reason for the difference in OpenStack, or is this just
>>>        how it was implemented? :)
>>>
>>>
>>>        I'd probably be writing a cron script to look at the database to
>>>        'terminate' instances in 'shutdown' state and thereby freeing
>>> their
>>>        resources...
>>>
>>>
>>>        Regards,
>>>
>>>        Tom
>>>
>>>
>>>        On 07/03/2011 11:44 PM, Terry.Rankine at csiro.au wrote:
>>>
>>>        Wont it need my EC2 credentials on the VM then?
>>>
>>>        The credentials used to start the VM are not stored on the VM. I
>>>        guess I can pass them in via the start-up string, but I would
>>>        prefer if there was another way.
>>>
>>>        Any other thoughts?
>>>
>>>        Terry
>>>        ______________________________**______
>>>        From: Mike Marrotte [marrotte at gmail.com
>>>        <mailto:marrotte at gmail.com> <mailto:marrotte at gmail.com
>>>
>>>        <mailto:marrotte at gmail.com>>]
>>>
>>>        Sent: Friday, 1 July 2011 7:47 PM
>>>        To: Rankine, Terry (CESRE, Kensington)
>>>        Cc:<openstack-operators at lists.**____openstack.org
>>>        <http://openstack.org>
>>>
>>>        <mailto:openstack-operators at __**lists.openstack.org<http://lists.openstack.org>
>>>        <mailto:openstack-operators@**lists.openstack.org<openstack-operators at lists.openstack.org>
>>> >>>
>>>
>>>        Subject: Re: [Openstack-operators] New to Open Stack - shutdown
>>>        vs terminate
>>>
>>>        Sure. Just install the euca2ools on the guest and write a script.
>>>
>>>        Sent from my iPhone
>>>
>>>        On Jul 1, 2011, at 1:07
>>>        AM,<Terry.Rankine at csiro.au<___**_mailto:Terry.Rankine at csiro.au
>>>        <mailto:Terry.Rankine at csiro.au**>
>>>        <mailto:Terry.Rankine at csiro.au
>>>        <mailto:Terry.Rankine at csiro.au**>__>>__> wrote:
>>>
>>>        Hi Guys
>>>        I am building an ‘worker image’ for an on-demand specific
>>>        ‘compute this’ workflow.
>>>        The image is totally aware of its success or failure of the
>>>        ‘compute this’ task, and uploads its output back to S3 storage.
>>>        Since the VM is the best thing to know about success/failure, I
>>>        figure it should also be the right thing to determine its end of
>>>        life (shutdown-dont destroy on failure for debugging, and
>>>        shutdown-terminate-release on success).
>>>        I would like it to automatically shutdown (and terminate
>>>        releasing all resources it held – public IP etc) on success, and
>>>        I would like the VM itself be able to do this. A ‘shutdown –h
>>>        now’ put the image into shutdown mode, but not terminated and
>>>        never released the held resources.
>>>        Is it possible for the VM to ‘shutdown and terminate’ itself?
>>>        Terry
>>>        ______________________________**_____________________
>>>        Openstack-operators mailing list
>>>        Openstack-operators at lists.__op**__enstack.org<http://op__enstack.org><
>>> http://openstack.org>
>>>
>>>        <mailto:Openstack-operators at __**lists.openstack.org<http://lists.openstack.org>
>>>        <mailto:Openstack-operators@**lists.openstack.org<Openstack-operators at lists.openstack.org>
>>> >><mailto:O**p__enstack__-operators at lists.<Op__enstack__-operators at lists.>
>>> _**_openstack.org
>>>
>>>        <mailto:Openstack__-operators@**lists.openstack.org<Openstack__-operators at lists.openstack.org>
>>> >
>>>
>>>        <mailto:Openstack-operators at __**lists.openstack.org<http://lists.openstack.org>
>>>        <mailto:Openstack-operators@**lists.openstack.org<Openstack-operators at lists.openstack.org>
>>> >>__>
>>>        http://lists.openstack.org/___**_cgi-bin/mailman/listinfo/____**
>>> openstack-operators<http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-operators>
>>>        <http://lists.openstack.org/__**cgi-bin/mailman/listinfo/__**
>>> openstack-operators<http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators>
>>> >
>>>        <http://lists.openstack.org/__**cgi-bin/mailman/listinfo/__**
>>> openstack-operators<http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators>
>>>        <http://lists.openstack.org/**cgi-bin/mailman/listinfo/**
>>> openstack-operators<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>
>>> >>
>>>        ______________________________**_____________________
>>>        Openstack-operators mailing list
>>>        Openstack-operators at lists.__op**__enstack.org<http://op__enstack.org><
>>> http://openstack.org>
>>>
>>>        <mailto:Openstack-operators at __**lists.openstack.org<http://lists.openstack.org>
>>>        <mailto:Openstack-operators@**lists.openstack.org<Openstack-operators at lists.openstack.org>
>>> >>
>>>        http://lists.openstack.org/___**_cgi-bin/mailman/listinfo/____**
>>> openstack-operators<http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-operators>
>>>        <http://lists.openstack.org/__**cgi-bin/mailman/listinfo/__**
>>> openstack-operators<http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators>
>>> >
>>>        <http://lists.openstack.org/__**cgi-bin/mailman/listinfo/__**
>>> openstack-operators<http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators>
>>>        <http://lists.openstack.org/**cgi-bin/mailman/listinfo/**
>>> openstack-operators<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>
>>> >>
>>>
>>>        ______________________________**_____________________
>>>        Openstack-operators mailing list
>>>        Openstack-operators at lists.__op**__enstack.org<http://op__enstack.org><
>>> http://openstack.org>
>>>
>>>        <mailto:Openstack-operators at __**lists.openstack.org<http://lists.openstack.org>
>>>        <mailto:Openstack-operators@**lists.openstack.org<Openstack-operators at lists.openstack.org>
>>> >>
>>>        http://lists.openstack.org/___**_cgi-bin/mailman/listinfo/____**
>>> openstack-operators<http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-operators>
>>>        <http://lists.openstack.org/__**cgi-bin/mailman/listinfo/__**
>>> openstack-operators<http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators>
>>> >
>>>        <http://lists.openstack.org/__**cgi-bin/mailman/listinfo/__**
>>> openstack-operators<http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators>
>>>        <http://lists.openstack.org/**cgi-bin/mailman/listinfo/**
>>> openstack-operators<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>
>>> >>
>>>
>>>
>>>
>>>  ______________________________**_________________
>> Openstack-operators mailing list
>> Openstack-operators at lists.**openstack.org<Openstack-operators at lists.openstack.org>
>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**
>> openstack-operators<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20110705/928d7a64/attachment-0002.html>