nova team mailing list archive
Mailing list archive
Re: Power states
On Wed, Aug 4, 2010 at 6:03 PM, Ewan Mellor <ewan.mellor@xxxxxxxxxxxxx> wrote:
> 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
> 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.
I would fully support using the Xen API's tuple of power states and
reasons for last shutdown as a replacement for the current
libvirt-specific stuff. Seems quite reasonable and much more
definitive than libvirt's states.