<div dir="ltr"><div>Hi,</div><div><br></div><div>On Tue, Oct 29, 2013 at 4:43 PM, Simon Boulet <<a href="mailto:simon@nostalgeek.com">simon@nostalgeek.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The libvirt "paused" method I<br>suggested is a hack that works with OpenNebula and turns the VM that<br>are internally shutdown to "SUSPENDED" in OpenNebula.</blockquote><div><br></div><div>Rubén could not retrieve that 'paused' state from libvirt, no matter how the vm was destroyed, he always got 'stopped'. Are we missing something?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">One comment though, perhaps the extra attribute in the VM template<br>
could be managed outside the core, and have this managed by a hook.<br>Ex. if someone wanted to have the Amazon<br>"instance-initiated-shutdown-behavior":<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">- Set the oned defaut when a VM disappears to POWEROFF.<br>
- Have a state change hooks that picks up the POWEROFF state change,<br>parse the VM template to see if an INITIATED_SHUTDOWN_BEHAVIOR user<br>attribute is set. If so, parse the attribute, if it's set to ex.<br>TERMINATE, cancel / delete the VM.</blockquote>
<div><br></div><div>I don't see any advantage to this, honestly. If you set the default behaviour to DONE, you can't undo that with a hook and set the VM back to poweroff...</div><div>Plus I think it's much safer to do it in the core. For example, when a Host returns a monitor failure, all the VMs are set to UNKNOWN. But this doesn't mean that the VM disappeared from the hypervisor, just that the VM could not be monitored.</div>
<div><br></div><div>Cheers</div><div>--</div><div>Carlos Martín, MSc</div><div>Project Engineer</div><div>OpenNebula - Flexible Enterprise Cloud Made Simple</div><div><a href="http://www.OpenNebula.org">www.OpenNebula.org</a> | <a href="mailto:cmartin@opennebula.org">cmartin@opennebula.org</a> | @OpenNebula</div>
<div class="gmail_extra"><br clear="all"><div><div dir="ltr">--<br><div>Carlos Martín, MSc<br>Project Engineer</div><div>OpenNebula - Flexible Enterprise Cloud Made Simple<br><div><span style="border-collapse:collapse;color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px"><a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:cmartin@opennebula.org" target="_blank">cmartin@opennebula.org</a> | <a href="http://twitter.com/opennebula" target="_blank">@OpenNebula</a></span><span style="border-collapse:collapse;color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px"><a href="mailto:cmartin@opennebula.org" style="color:rgb(42,93,176)" target="_blank"></a></span></div>
</div></div></div>
<br><br><div class="gmail_quote">On Tue, Oct 29, 2013 at 4:43 PM, Simon Boulet <span dir="ltr"><<a href="mailto:simon@nostalgeek.com" target="_blank">simon@nostalgeek.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi Carlos<br>
<div class="im"><br>
> We could have a global default in oned.conf, and then allow to change the behaviour with an attribute in the<br>
> VM template. This wouldn't require any extra hooks, and it would work with any hypervisor.<br>
><br>
<br>
</div>I think thats the ideal solution! The libvirt "paused" method I<br>
suggested is a hack that works with OpenNebula and turns the VM that<br>
are internally shutdown to "SUSPENDED" in OpenNebula.<br>
<br>
One comment though, perhaps the extra attribute in the VM template<br>
could be managed outside the core, and have this managed by a hook.<br>
Ex. if someone wanted to have the Amazon<br>
"instance-initiated-shutdown-behavior":<br>
<br>
- Set the oned defaut when a VM disappears to POWEROFF.<br>
- Have a state change hooks that picks up the POWEROFF state change,<br>
parse the VM template to see if an INITIATED_SHUTDOWN_BEHAVIOR user<br>
attribute is set. If so, parse the attribute, if it's set to ex.<br>
TERMINATE, cancel / delete the VM.<br>
<span class=""><font color="#888888"><br>
Simon<br>
</font></span><div class=""><div class="h5"><br>
On Tue, Oct 29, 2013 at 7:58 AM, Carlos Martín Sánchez<br>
<<a href="mailto:cmartin@opennebula.org">cmartin@opennebula.org</a>> wrote:<br>
> Hi,<br>
><br>
> I find this thread interesting, especially the<br>
> --instance-initiated-shutdown-behavior option.<br>
> In our case, when the driver reports that the VM has disappeared, we could<br>
> choose to move it to the following states: unknown, done, poweroff,<br>
> undeployed.<br>
><br>
> We could have a global default in oned.conf, and then allow to change the<br>
> behaviour with an attribute in the VM template. This wouldn't require any<br>
> extra hooks, and it would work with any hypervisor.<br>
><br>
> What do you guys think?<br>
> --<br>
> Carlos Martín, MSc<br>
> Project Engineer<br>
> OpenNebula - Flexible Enterprise Cloud Made Simple<br>
> <a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:cmartin@opennebula.org">cmartin@opennebula.org</a> | @OpenNebula<br>
><br>
><br>
> On Thu, Oct 10, 2013 at 9:30 PM, Nistor Andrei <<a href="mailto:coder.tux@gmail.com">coder.tux@gmail.com</a>> wrote:<br>
>><br>
>> Hi Ruben,<br>
>><br>
>> Do we really care if the VM was shut down from the inside or not? I was<br>
>> thinking of a hook script like the following:<br>
>><br>
>> #!/bin/bash<br>
>><br>
>> VMID=$(echo $1 | cut -d- -f2)<br>
>><br>
>> if [ $2 == "stopped" ]; then<br>
>> onevm shutdown $VMID<br>
>> fi<br>
>><br>
>> It's obviously just a big fat (untested) hack, which will probably<br>
>> backfire when you use onevm poweroff or onevm stop.<br>
>><br>
>> Anyway, the point is that we can use those hooks to notify oned that the<br>
>> VM is shut down. Then oned can decide if the shut down was initiated by the<br>
>> user via onevm {shutdown,poweroff,stop}, in which case it would take the<br>
>> appropriate action. If it wasn't initiated via onevm* commands, but was<br>
>> initiated by the guest itself, we can take some configurable action -- shut<br>
>> it down for batch jobs, or power it off for say... hosting customers.<br>
>><br>
>> Cheers,<br>
>><br>
>> Andrei<br>
>><br>
>> On Thu, Oct 10, 2013 at 12:38 PM, Ruben S. Montero<br>
>> <<a href="mailto:rsmontero@opennebula.org">rsmontero@opennebula.org</a>> wrote:<br>
>>><br>
>>> Hi Simon + Nistor,<br>
>>><br>
>>> We've done some tests in the stock drivers when the VM is shutdown (from<br>
>>> inside) the VM disappears from the list, show we cannot get the state (not<br>
>>> even with --all). How do you get the paused state?<br>
>>><br>
>>> On the other hand, the libvirt hook seems a good approach, since we could<br>
>>> create a file in the VM directory (e.g. .shutdown-inside) and report the<br>
>>> state accordingly. However we made some tests and there is no difference<br>
>>> between the two.<br>
>>><br>
>>> This hook:<br>
>>><br>
>>> #!/bin/bash<br>
>>><br>
>>> echo "`date`: $*" >> /tmp/hook<br>
>>><br>
>>> Gives the same in both cases:<br>
>>><br>
>>> Thu Oct 10 11:27:56 CEST 2013: one-17 stopped end - <---- shutdown<br>
>>> inside<br>
>>> Thu Oct 10 11:27:56 CEST 2013: one-17 release end -<br>
>>> Thu Oct 10 11:33:07 CEST 2013: one-17 prepare begin -<br>
>>> Thu Oct 10 11:33:07 CEST 2013: one-17 start begin - <---- boot<br>
>>> Thu Oct 10 11:33:07 CEST 2013: one-17 started begin -<br>
>>> Thu Oct 10 11:34:02 CEST 2013: one-17 stopped end - <---- shutdown via<br>
>>> libvirt<br>
>>> Thu Oct 10 11:34:02 CEST 2013: one-17 release end -<br>
>>><br>
>>> So, the real problem is how to determine if the VM has been shutdown from<br>
>>> inside or not....<br>
>>><br>
>>> Cheers<br>
>>><br>
>>> Ruben<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On Mon, Oct 7, 2013 at 12:37 PM, Nistor Andrei <<a href="mailto:coder.tux@gmail.com">coder.tux@gmail.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> Hi,<br>
>>>><br>
>>>> Maybe you can use libvirt hooks[1] to notify oned via the xmlrpc that<br>
>>>> the VMs have shut down?<br>
>>>><br>
>>>> [1] <a href="http://libvirt.org/hooks.html" target="_blank">http://libvirt.org/hooks.html</a><br>
>>>><br>
>>>> Andrei<br>
>>>><br>
>>>><br>
>>>> On Fri, Oct 4, 2013 at 6:45 PM, Simon Boulet <<a href="mailto:simon@nostalgeek.com">simon@nostalgeek.com</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> Hi,<br>
>>>>><br>
>>>>> Here our driver reports the state as returned by Libvirt [1], which<br>
>>>>> reports VM terminated from the inside (shutdown) as Paused. When the<br>
>>>>> OpenNebula driver sees a VM as being reported as paused [2], it<br>
>>>>> switches the VM to SUSPENDED state in OpenNebula. Then you can restart<br>
>>>>> the VM by issuing the resume action [3].<br>
>>>>><br>
>>>>> So, I think OpenNebula has the building blocks for that, but I'm just<br>
>>>>> unsure how it is implemented in the different OpenNebula drivers.<br>
>>>>><br>
>>>>> [1]<br>
>>>>> <a href="http://wiki.libvirt.org/page/VM_lifecycle#States_that_a_guest_domain_can_be_in" target="_blank">http://wiki.libvirt.org/page/VM_lifecycle#States_that_a_guest_domain_can_be_in</a><br>
>>>>> [2]<br>
>>>>> <a href="http://opennebula.org/documentation:rel4.2:devel-vmm#poll_information" target="_blank">http://opennebula.org/documentation:rel4.2:devel-vmm#poll_information</a><br>
>>>>> [3] <a href="http://opennebula.org/documentation:rel4.2:api#onevmaction" target="_blank">http://opennebula.org/documentation:rel4.2:api#onevmaction</a><br>
>>>>><br>
>>>>> Simon<br>
>>>>><br>
>>>>> On Fri, Oct 4, 2013 at 9:43 AM, Parag Mhashilkar <<a href="mailto:parag@fnal.gov">parag@fnal.gov</a>><br>
>>>>> wrote:<br>
>>>>> > Hi Sharuzzaman,<br>
>>>>> ><br>
>>>>> > Thanks for your response. I am aware of the fact that OpenNebula<br>
>>>>> > requires human intervention when shutdown is issued from inside the VM. We<br>
>>>>> > can write scripts to do lot of things, but when in the business of resource<br>
>>>>> > provisioning, the resource provider does not necessarily control what runs<br>
>>>>> > in the VM, application that launches them and for obvious reasons I am not<br>
>>>>> > giving any access to ONE's database to the users. So these alternatives seem<br>
>>>>> > merely hacks rather than a much cleaner solution from the service.<br>
>>>>> ><br>
>>>>> > Such a feature is useful from a infrastructure provider's point of<br>
>>>>> > view. If AWS has done it (and Openstack I think) then there be a way out.<br>
>>>>> ><br>
>>>>> > -Parag<br>
>>>>> ><br>
>>>>> ><br>
>>>>> > On Oct 3, 2013, at 9:27 PM, Sharuzzaman Ahmat Raslan wrote:<br>
>>>>> ><br>
>>>>> >> Hi Parag,<br>
>>>>> >><br>
>>>>> >> I believe OpenNebula need to have human intervention to really<br>
>>>>> >> determine whether to remove or not the VM that it has deployed.<br>
>>>>> >><br>
>>>>> >> I also think that you can write a script that signal or call<br>
>>>>> >> OpenNebula command as soon as the task finish, to shutdown the VM. Or if<br>
>>>>> >> direct calling command not possible, maybe your application can write some<br>
>>>>> >> status in a database, and a script in OpenNebula read that status and make<br>
>>>>> >> decision from it.<br>
>>>>> >><br>
>>>>> >> Thanks.<br>
>>>>> >><br>
>>>>> >><br>
>>>>> >> On Thu, Oct 3, 2013 at 11:38 PM, Parag Mhashilkar <<a href="mailto:parag@fnal.gov">parag@fnal.gov</a>><br>
>>>>> >> wrote:<br>
>>>>> >> Hi,<br>
>>>>> >><br>
>>>>> >> Does OpenNebula EC2 interface support shutting down a VM from with<br>
>>>>> >> in the VM itself and have the scheduler recognize that VM has been<br>
>>>>> >> stopped/shutdown? How do we enable this feature? At Fermi, we have<br>
>>>>> >> OpenNebula v3.2 and when the VM is shutdown it stays in the UNKNOWN state.<br>
>>>>> >> Can OpenNebula get this ACPI shutdown info from virsh and handle the<br>
>>>>> >> situation more gracefully rather than putting the VM in UKNOWN state?<br>
>>>>> >><br>
>>>>> >> Here is an example why I think something like this is useful:<br>
>>>>> >><br>
>>>>> >> When VMs are launched to perform certain tasks (classical equivalent<br>
>>>>> >> of batch nodes), only the processes running in the VM know when the task is<br>
>>>>> >> done and can shutdown the VM freeing up the resources. Running VM past the<br>
>>>>> >> task life is wasted resources and controlling the lifetime of VM from<br>
>>>>> >> outside is not always possible.<br>
>>>>> >><br>
>>>>> >> In case of AWS, it supports following which is very good feature to<br>
>>>>> >> have when controlling the VMs in above scenario.<br>
>>>>> >> ec2-run-instaces --instance-initiated-shutdown-behavior<br>
>>>>> >> <stop|terminate><br>
>>>>> >><br>
>>>>> >> How do we achieve this with Opennebula?<br>
>>>>> >><br>
>>>>> >> Thanks & Regards<br>
>>>>> >> +==========================================================<br>
>>>>> >> | Parag Mhashilkar<br>
>>>>> >> | Fermi National Accelerator Laboratory, MS 120<br>
>>>>> >> | Wilson & Kirk Road, Batavia, IL - 60510<br>
>>>>> >> |----------------------------------------------------------<br>
>>>>> >> | Phone: <a href="tel:1%20%28630%29%20840-6530" value="+16308406530">1 (630) 840-6530</a> Fax: <a href="tel:1%20%28630%29%20840-2783" value="+16308402783">1 (630) 840-2783</a><br>
>>>>> >> |----------------------------------------------------------<br>
>>>>> >> | Wilson Hall, 806E (Nov 8, 2012 - To date)<br>
>>>>> >> | Wilson Hall, 867E (Nov 17, 2010 - Nov 7, 2012)<br>
>>>>> >> | Wilson Hall, 863E (Apr 24, 2007 - Nov 16, 2010)<br>
>>>>> >> | Wilson Hall, 856E (Mar 21, 2005 - Apr 23, 2007)<br>
>>>>> >> +==========================================================<br>
>>>>> >><br>
>>>>> >><br>
>>>>> >> _______________________________________________<br>
>>>>> >> Users mailing list<br>
>>>>> >> <a href="mailto:Users@lists.opennebula.org">Users@lists.opennebula.org</a><br>
>>>>> >> <a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a><br>
>>>>> >><br>
>>>>> >><br>
>>>>> >><br>
>>>>> >><br>
>>>>> >> --<br>
>>>>> >> Sharuzzaman Ahmat Raslan<br>
>>>>> ><br>
>>>>> ><br>
>>>>> > _______________________________________________<br>
>>>>> > Users mailing list<br>
>>>>> > <a href="mailto:Users@lists.opennebula.org">Users@lists.opennebula.org</a><br>
>>>>> > <a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a><br>
>>>>> ><br>
>>>>> _______________________________________________<br>
>>>>> Users mailing list<br>
>>>>> <a href="mailto:Users@lists.opennebula.org">Users@lists.opennebula.org</a><br>
>>>>> <a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> Users mailing list<br>
>>>> <a href="mailto:Users@lists.opennebula.org">Users@lists.opennebula.org</a><br>
>>>> <a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a><br>
>>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> --<br>
>>> Ruben S. Montero, PhD<br>
>>> Project co-Lead and Chief Architect<br>
>>> OpenNebula - Flexible Enterprise Cloud Made Simple<br>
>>> <a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:rsmontero@opennebula.org">rsmontero@opennebula.org</a> | @OpenNebula<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Users mailing list<br>
>> <a href="mailto:Users@lists.opennebula.org">Users@lists.opennebula.org</a><br>
>> <a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.opennebula.org">Users@lists.opennebula.org</a><br>
> <a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a><br>
><br>
</div></div></blockquote></div><br></div></div>