nova team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

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
>> 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.

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.

-jay