Graceful shutdown of VMs
|Assignee:||Ruben S. Montero||% Done:|
|Category:||Core & System|
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...
#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:)
#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:)