Lock an instance from reboot if suspended.

Registered by Sandy Walsh

Lock an instance so it does not start back up even if the user sends a reboot signal to the host.
The instance would then be in a suspended and locked state.

Blueprint information

Rick Clark
Paul Voccio
Needs approval
Trey Morris
Series goal:
Accepted for bexar
Milestone target:
Started by
Sandy Walsh
Completed by
Thierry Carrez

Related branches



Thoughts on the locking portion:
We need suspend as a power state (ram goes to disk, instance is shut down) as well as a locking suspend (ram goes to disk, instance is shut down, instance is no longer customer bootable) which make sense from a billing point of view. The issue is where this lock is going to be. For example, in Xenserver we can set whether an instance is bootable, but I'm unsure if this feature is supported in other hypervisors. Even if it were supported across the hypervisor board this would be a specific case of lock (locking the instance in a shutdown/suspend type state). Instead, I propose a state lock. When an instance is state locked, no functions which enact a change in state may be executed. State lock would be above the hypervisor level and require storage in a table. Being above the hypervisor level gives us the advantage of not having to implement boot lock functionality in each hypervisor api and we get a more general lock feature which can be used in more situations. I don't like the idea of all the compute worker functions having to check for state lock status because it's ugly as well as code duplication, but I'm not sure of a better way at the moment.

I'm looking for suggestions/comments on the general state lock idea vs hypervisor boot lock vs implementing locking at all within nova, as well as ideas for a clean implementation of a state lock if the idea is agreeable.

Current Proposal:
db/logical lock, I dislike the idea of a vm lock. Shouldn't have to code around mistakes ops could make and I also have more faith in ops. Hypervisors should be configured to reboot or start up without rebooting/restarting all instances. I think it makes much more sense to write code for the compute worker to handle resetting a host or handle a host going down. The scenario I envision is a xenserver goes down, and whether the compute worker is coded to notice or it's manually told to, it goes through all of the instances on that host and handles each's previous state accordingly: shutdown instances are ignored, running instances are restarted, other states my require more thinking since, for example, it might not make sense to restart an instance that was paused and then pause it.

To sum up: nothing but the compute worker should be changing the state of instances on the hypervisor. If something else manages to do so, the compute worker should be able to handle that situation gracefully.


Work Items

This blueprint contains Public information 
Everyone can see this information.