Request #242

Graceful shutdown of VMs

Added by Gyula Csom about 11 years ago. Updated over 10 years ago.

Status:ClosedStart date:05/15/2010
Priority:NormalDue date:
Assignee:Ruben S. Montero% Done:


Category:Core & System
Target version:-
Pull request:


we'd like to support vm shutdowns, eg. let users to gracefully shutdown their machines and later restart them. Is there any plan in this regard?

Below the fold...

  • Of course users can shutdown their machines within the machines themselves. However it would be handy to support the command within the cloud management layer, too.
  • Shutdown is related to reboot (Issue #132) since reboot is equivalent with shutdown+restart.
  • Since restart, and hibernate (eg. stop, resume) are already built into ONE, and reboot will be soon implemented, it might be nifty to support their counterpart, too.
  • Regarding the platform... We'll use KVM as the hypervisor and both KVM and libvirt seems to provide shutdown, well if acpi is supported by the guest OS...


Associated revisions

Revision ba69ddcd
Added by Abel Coronado over 4 years ago

Backlog #3628 Removed Files from context for vCenter templates (#242)


#1 Updated by Ruben S. Montero about 11 years ago


I think OpenNebula already supports this. If you issue a onevm shutdown command the VM will be gracefully shutdown. Additionally if you want to preserve the state you can label the VM disks with save=yes. Later the user can use that disk to restart the VM. OpenNebula does not overwrite the original disk, but if you want you can easily achieve this with a hook (simply mv's $ONE_LOCATION/var/$VMID/disk.0 to the original file...)

#2 Updated by Gyula Csom about 11 years ago

thanx for your feedback!

According to our previous tests, we couldn't restart a shutdown VM, just delete it.
So I thought the built in shutdown command meant end of life. Since I might mess up
something I'll rerun the tests to see what is happening:)


#3 Updated by Ruben S. Montero about 11 years ago

Well, yes you have to "resubmit", i.e. onevm create, but it will use the modified VM images. So onevm create == restart. Right now, we do not have a template DB...

#4 Updated by Gyula Csom about 11 years ago

Ok, I see the point, thank you:)

#5 Updated by Gyula Csom about 11 years ago

There's a problem related to dynamic IP assignment. In our context we have to support virtual clusters, but the issue is more general, it can come up in any context when there's more then one VM within a virtual network (which is very likely:)).

Example: Assume that the VM had a public IP assigned to it dynamically (eg. from a range network), and the user stoped, then later restarted it with the above "resubmit" approach. Then it might happen that an intermediate VM request already allocated its previous IP address, thus the system can do nothing but assign a new public IP.

Please consider my request in your future plans:)


#6 Updated by Ruben S. Montero about 11 years ago


Then why not taking out the IP you want to keep for that VM from the VNet? However, there are some benefits of keeping the VM defined in DB. When a VM is shutdown it will end in a DONE state, this is we dispose the template and free the associated resources (like IP's). It would be more or less straight forward to move the VM to the HOLD state if it is marked to be kept.


1. Standard life cycle, the current one (simplified)

(create)---> PENDING ---(deploy)---> RUNNING ---(shutdown)--->DONE 

2.- Keep VM template

(define) ---> HOLD ---(release) ---> PENDING ---(deploy)---> RUNNING ---(shutdown)
               ^                                                             |
               |---------------- (will not free network leases) --------------

Note that the resources used by the VM in the physical workernode are freed and when you release the VM it can end up in other physical workernode...

Does it make sense?


#7 Updated by Gyula Csom about 11 years ago


taking out the IP from the VNet is new thing for me:) To my understanding this could be done by resubmiting the VNet (delete -> take out the IP -> recreate the VNet). Does this work when there are active leases? As far as I see it shouldn't... since it would mess up the lease logic... But again I could be wrong.

I put my vote on the create/define scenarios:)


#8 Updated by Ruben S. Montero over 10 years ago

  • Status changed from New to Closed

This is now address with the new resubmit action. Also the future VM template repository will help to implement the functionality described here

Also available in: Atom PDF