| Thread Previous • Date Previous • Date Next • Thread Next |
On Wed, Aug 04, 2010 at 09:52:28PM +0100, Jay Pipes wrote: > > This is not how they're being used in the code though. In particular, when > > we get an exception during spawn we set the state to SHUTDOWN (in libvirt > > semantics, "being shut down") and when destroying a VM, we wait for it to > > transition to SHUTDOWN, rather than SHUTOFF. > > Yes, that is indeed inconsistent. In the case of the exception during > spawn, what would be the state you suggest transitioning to? Perhaps > CRASHED? In XenAPI, we have three axes, if that's the right term: The actual state of the VM, as observed by the virtualization layer: Running, Halted, Suspended, Paused. Tasks that are in progress: start, clean reboot, or clean shutdown, for example. Reasons for the last shutdown: it crashed, it shut down by itself, it was asked to shut down by the platform, it was hard powered off by the platform. The power states are definitive: a VM is either running, or it isn't. The tasks are transitory, and may trigger a power state transition, e.g. a clean shutdown task will cause a transition from Running to Halted once it is complete (or it will fail, and the VM will stay in state Running). The shutdown reasons are there to record the necessary information without exploding the state space. A VM that has crashed at the end of the day is still Halted. The fact that it crashed is useful information, but ultimately its now indistinguishable from a VM that was powered off -- they are both merely Halted. > In the case of destroying a VM, that looks like it may be a > copy-paste error? Quite possibly, given how confusing the SHUTDOWN name is. Cheers, Ewan.
| Thread Previous • Date Previous • Date Next • Thread Next |
