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

Nistor Andrei coder.tux at gmail.com
Thu Oct 10 12:30:08 PDT 2013


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20131010/e203eeae/attachment-0002.htm>


More information about the Users mailing list