<h3>
</h3><p><a href="http://libvirt.org/formatdomain.html"> http://libvirt.org/formatdomain.html</a></p>
<h3><a name="elementsLifecycle" id="elementsLifecycle">Lifecycle control</a>
</h3>
<p>
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.
</p>
<pre> ...
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
...</pre>
<dl><dt><code>on_poweroff</code></dt><dd>The content of this element specifies the action to take when
the guest requests a poweroff.</dd><dt><code>on_reboot</code></dt><dd>The content of this element specifies the action to take when
the guest requests a reboot.</dd><dt><code>on_crash</code></dt><dd>The content of this element specifies the action to take when
the guest crashes.</dd></dl><p>Each of these states allow for the same four possible actions.
</p>
<dl><dt><code>destroy</code></dt><dd>The domain will be terminated completely and all resources
released</dd><dt><code>restart</code></dt><dd>The domain will be terminated, and then restarted with
the same configuration</dd><dt><code>preserve</code></dt><dd>The domain will be terminated, and its resource preserved
to allow analysis.</dd><dt><code>rename-restart</code></dt><dd>The domain will be terminated, and then restarted with
a new name</dd></dl>
<p>
on_crash supports these additional
actions <span class="since">since 0.8.4</span>.
</p>
<dl><dt><code>coredump-destroy</code></dt><dd>The crashed domain's core will be dumped, and then the
domain will be terminated completely and all resources
released</dd><dt><code>coredump-restart</code></dt><dd>The crashed domain's core will be dumped, and then the
domain will be restarted with the same configuration</dd></dl><br><br><div class="gmail_quote">On Tue, Jul 5, 2011 at 10:52 AM, Michael Marrotte <span dir="ltr"><<a href="mailto:marrotte@gmail.com">marrotte@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">At least for KVM, I think you can add something like <on_poweroff>destroy</on_poweroff> to VM definsiont file...<div>
<div></div><div class="h5"><br><br><div class="gmail_quote">On Tue, Jul 5, 2011 at 8:48 AM, Tom Fifield <span dir="ltr"><<a href="mailto:fifieldt@unimelb.edu.au" target="_blank">fifieldt@unimelb.edu.au</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Thanks again - unfortunately this is similar to what Mike Marrotte wrote in a previous email.<br>
<br>
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 :)<br>
<br>
Regards,<br>
<br>
Tom<div><br>
<br>
On 07/05/2011 10:45 PM, Leandro Reox wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Tom ,<br>
<br><div>
Just thinking out loud, maybe you can pass out your API credentials via<br>
metadata in boot time, and then use them to :<br>
<br>
- When a user issues "shutdown -h" , is really an alias to post a<br>
"Terminate" to the nova API<br>
- Then the instance "suicides" itself and you get what your users are<br>
expecting :)<br>
<br>
Regards<br>
<br>
Lele<br>
<br>
<br>
<br>
On Tue, Jul 5, 2011 at 9:36 AM, Tom Fifield <<a href="mailto:fifieldt@unimelb.edu.au" target="_blank">fifieldt@unimelb.edu.au</a><br></div><div><div></div><div>
<mailto:<a href="mailto:fifieldt@unimelb.edu.au" target="_blank">fifieldt@unimelb.edu.<u></u>au</a>>> wrote:<br>
<br>
Hi,<br>
<br>
Thanks for your reply!<br>
<br>
I'm dealing with a lot of users who expect the same style as Amazon,<br>
which as I mentioned below is that within a guest VM 'shutdown -h<br>
now' is like saying "I don't want this instance anymore". This is<br>
the 'terminate' state for guest VMs, hence the cron to clean it up.<br>
<br>
Good point about recovery from nova-compute host issues though. We<br>
only want to terminate instances that have been taken down by the<br>
user, rather than ourselves ;)<br>
<br>
Regards,<br>
<br>
Tom<br>
<br>
<br>
On 07/05/2011 10:29 PM, Leandro Reox wrote:<br>
<br>
Tom,<br>
<br>
I dont know if croning the "Terminate" for instances in<br>
"shutdown" state<br>
is a good idea, after a Physical node restart the instances<br>
running in<br>
that node stays in shutdown mode after the node comes back, you can<br>
"re-awake" them by issuing nova reboot, maybe a cleaner an usefull<br>
script will try to "reboot" the instance and if doest succeed<br>
terminate<br>
them, just an idea.<br>
<br>
Regards<br>
Lele<br>
<br>
On Tue, Jul 5, 2011 at 1:50 AM, Tom Fifield<br>
<<a href="mailto:fifieldt@unimelb.edu.au" target="_blank">fifieldt@unimelb.edu.au</a> <mailto:<a href="mailto:fifieldt@unimelb.edu.au" target="_blank">fifieldt@unimelb.edu.<u></u>au</a>><br>
<mailto:<a href="mailto:fifieldt@unimelb.edu." target="_blank">fifieldt@unimelb.edu.</a>_<u></u>_au<br>
<mailto:<a href="mailto:fifieldt@unimelb.edu.au" target="_blank">fifieldt@unimelb.edu.<u></u>au</a>>>> wrote:<br>
<br>
Hi,<br>
<br>
Echoing this request - it's very handy on Amazon EC2 when a shutdown<br>
-h now command results in instance termination.<br>
<br>
Is there a reason for the difference in OpenStack, or is this just<br>
how it was implemented? :)<br>
<br>
<br>
I'd probably be writing a cron script to look at the database to<br>
'terminate' instances in 'shutdown' state and thereby freeing their<br>
resources...<br>
<br>
<br>
Regards,<br>
<br>
Tom<br>
<br>
<br>
On 07/03/2011 11:44 PM, Terry.Rankine@csiro.au wrote:<br>
<br>
Wont it need my EC2 credentials on the VM then?<br>
<br>
The credentials used to start the VM are not stored on the VM. I<br>
guess I can pass them in via the start-up string, but I would<br>
prefer if there was another way.<br>
<br>
Any other thoughts?<br>
<br>
Terry<br>
______________________________<u></u>______<br>
From: Mike Marrotte [<a href="mailto:marrotte@gmail.com" target="_blank">marrotte@gmail.com</a><br></div></div>
<mailto:<a href="mailto:marrotte@gmail.com" target="_blank">marrotte@gmail.com</a>> <mailto:<a href="mailto:marrotte@gmail.com" target="_blank">marrotte@gmail.com</a><div><br>
<mailto:<a href="mailto:marrotte@gmail.com" target="_blank">marrotte@gmail.com</a>>>]<br>
<br>
Sent: Friday, 1 July 2011 7:47 PM<br>
To: Rankine, Terry (CESRE, Kensington)<br>
Cc:<openstack-operators@lists.<u></u>____<a href="http://openstack.org" target="_blank">openstack.org</a><br></div>
<<a href="http://openstack.org" target="_blank">http://openstack.org</a>><div><div></div><div><br>
<mailto:<a href="mailto:openstack-operators@" target="_blank">openstack-operators@</a>__<a href="http://lists.openstack.org" target="_blank"><u></u>lists.openstack.org</a><br>
<mailto:<a href="mailto:openstack-operators@lists.openstack.org" target="_blank">openstack-operators@<u></u>lists.openstack.org</a>>>><br>
<br>
Subject: Re: [Openstack-operators] New to Open Stack - shutdown<br>
vs terminate<br>
<br>
Sure. Just install the euca2ools on the guest and write a script.<br>
<br>
Sent from my iPhone<br>
<br>
On Jul 1, 2011, at 1:07<br>
AM,<Terry.Rankine@csiro.au<___<u></u>_mailto:<a href="mailto:Terry.Rankine@csiro.au" target="_blank">Terry.Rankine@csiro.au</a><br>
<mailto:<a href="mailto:Terry.Rankine@csiro.au" target="_blank">Terry.Rankine@csiro.au</a><u></u>><br>
<mailto:<a href="mailto:Terry.Rankine@csiro.au" target="_blank">Terry.Rankine@csiro.au</a><br>
<mailto:<a href="mailto:Terry.Rankine@csiro.au" target="_blank">Terry.Rankine@csiro.au</a><u></u>>__>>__> wrote:<br>
<br>
Hi Guys<br>
I am building an ‘worker image’ for an on-demand specific<br>
‘compute this’ workflow.<br>
The image is totally aware of its success or failure of the<br>
‘compute this’ task, and uploads its output back to S3 storage.<br>
Since the VM is the best thing to know about success/failure, I<br>
figure it should also be the right thing to determine its end of<br>
life (shutdown-dont destroy on failure for debugging, and<br>
shutdown-terminate-release on success).<br>
I would like it to automatically shutdown (and terminate<br>
releasing all resources it held – public IP etc) on success, and<br>
I would like the VM itself be able to do this. A ‘shutdown –h<br>
now’ put the image into shutdown mode, but not terminated and<br>
never released the held resources.<br>
Is it possible for the VM to ‘shutdown and terminate’ itself?<br>
Terry<br>
______________________________<u></u>_____________________<br>
Openstack-operators mailing list<br></div></div>
Openstack-operators@lists.__<a href="http://op__enstack.org" target="_blank">op<u></u>__enstack.org</a> <<a href="http://openstack.org" target="_blank">http://openstack.org</a>><div><br>
<mailto:<a href="mailto:Openstack-operators@" target="_blank">Openstack-operators@</a>__<a href="http://lists.openstack.org" target="_blank"><u></u>lists.openstack.org</a><br></div>
<mailto:<a href="mailto:Openstack-operators@lists.openstack.org" target="_blank">Openstack-operators@<u></u>lists.openstack.org</a>>><mailto:<a href="mailto:Op__enstack__-operators@lists." target="_blank">O<u></u>p__enstack__-operators@lists.</a>_<u></u>_<a href="http://openstack.org" target="_blank">openstack.org</a><div>
<br>
<mailto:<a href="mailto:Openstack__-operators@lists.openstack.org" target="_blank">Openstack__-operators@<u></u>lists.openstack.org</a>><br>
<br>
<mailto:<a href="mailto:Openstack-operators@" target="_blank">Openstack-operators@</a>__<a href="http://lists.openstack.org" target="_blank"><u></u>lists.openstack.org</a><br>
<mailto:<a href="mailto:Openstack-operators@lists.openstack.org" target="_blank">Openstack-operators@<u></u>lists.openstack.org</a>>>__><br>
<a href="http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-operators" target="_blank">http://lists.openstack.org/___<u></u>_cgi-bin/mailman/listinfo/____<u></u>openstack-operators</a><br>
<<a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators" target="_blank">http://lists.openstack.org/__<u></u>cgi-bin/mailman/listinfo/__<u></u>openstack-operators</a>><br>
<<a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators" target="_blank">http://lists.openstack.org/__<u></u>cgi-bin/mailman/listinfo/__<u></u>openstack-operators</a><br>
<<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-operators</a>>><br>
______________________________<u></u>_____________________<br>
Openstack-operators mailing list<br></div>
Openstack-operators@lists.__<a href="http://op__enstack.org" target="_blank">op<u></u>__enstack.org</a> <<a href="http://openstack.org" target="_blank">http://openstack.org</a>><div><br>
<mailto:<a href="mailto:Openstack-operators@" target="_blank">Openstack-operators@</a>__<a href="http://lists.openstack.org" target="_blank"><u></u>lists.openstack.org</a><br>
<mailto:<a href="mailto:Openstack-operators@lists.openstack.org" target="_blank">Openstack-operators@<u></u>lists.openstack.org</a>>><br>
<a href="http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-operators" target="_blank">http://lists.openstack.org/___<u></u>_cgi-bin/mailman/listinfo/____<u></u>openstack-operators</a><br>
<<a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators" target="_blank">http://lists.openstack.org/__<u></u>cgi-bin/mailman/listinfo/__<u></u>openstack-operators</a>><br>
<<a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators" target="_blank">http://lists.openstack.org/__<u></u>cgi-bin/mailman/listinfo/__<u></u>openstack-operators</a><br>
<<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-operators</a>>><br>
<br>
______________________________<u></u>_____________________<br>
Openstack-operators mailing list<br></div>
Openstack-operators@lists.__<a href="http://op__enstack.org" target="_blank">op<u></u>__enstack.org</a> <<a href="http://openstack.org" target="_blank">http://openstack.org</a>><div><br>
<mailto:<a href="mailto:Openstack-operators@" target="_blank">Openstack-operators@</a>__<a href="http://lists.openstack.org" target="_blank"><u></u>lists.openstack.org</a><br>
<mailto:<a href="mailto:Openstack-operators@lists.openstack.org" target="_blank">Openstack-operators@<u></u>lists.openstack.org</a>>><br>
<a href="http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-operators" target="_blank">http://lists.openstack.org/___<u></u>_cgi-bin/mailman/listinfo/____<u></u>openstack-operators</a><br>
<<a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators" target="_blank">http://lists.openstack.org/__<u></u>cgi-bin/mailman/listinfo/__<u></u>openstack-operators</a>><br>
<<a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators" target="_blank">http://lists.openstack.org/__<u></u>cgi-bin/mailman/listinfo/__<u></u>openstack-operators</a><br>
<<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-operators</a>>><br>
<br>
<br>
<br>
</div></blockquote><div><div></div><div>
______________________________<u></u>_________________<br>
Openstack-operators mailing list<br>
<a href="mailto:Openstack-operators@lists.openstack.org" target="_blank">Openstack-operators@lists.<u></u>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-operators</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>