[one-users] Shutting down a VM from within the VM

Tue Oct 29 08:43:08 PDT 2013

Hi Carlos

> We could have a global default in oned.conf, and then allow to change the behaviour with an attribute in the
> VM template. This wouldn't require any extra hooks, and it would work with any hypervisor.
>

I think thats the ideal solution! The libvirt "paused" method I
suggested is a hack that works with OpenNebula and turns the VM that
are internally shutdown to "SUSPENDED" in OpenNebula.

One comment though, perhaps the extra attribute in the VM template
could be managed outside the core, and have this managed by a hook.
Ex. if someone wanted to have the Amazon
"instance-initiated-shutdown-behavior":

- Set the oned defaut when a VM disappears to POWEROFF.
- Have a state change hooks that picks up the POWEROFF state change,
parse the VM template to see if an INITIATED_SHUTDOWN_BEHAVIOR user
attribute is set. If so, parse the attribute, if it's set to ex.
TERMINATE, cancel / delete the VM.

Simon

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