nova team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

Heya, comments inline...

On Wed, Aug 4, 2010 at 6:13 AM, Ewan Mellor <ewan.mellor@xxxxxxxxxxxxx> wrote:
> We have the following VM power states defined in compute.power_state (recently
> moved from compute.node):
>
> NOSTATE = 0x00
> RUNNING = 0x01
> BLOCKED = 0x02
> PAUSED = 0x03
> SHUTDOWN = 0x04
> SHUTOFF = 0x05
> CRASHED = 0x06
>
> Does anyone know what the intended semantics are of these?  They look like the
> libvirt states, which are defined thus:
>
> enum virDomainState {
> VIR_DOMAIN_NOSTATE =  0 : no state
> VIR_DOMAIN_RUNNING =  1 : the domain is running
> VIR_DOMAIN_BLOCKED =  2 : the domain is blocked on resource
> VIR_DOMAIN_PAUSED =  3 : the domain is paused by user
> VIR_DOMAIN_SHUTDOWN =  4 : the domain is being shut down
> VIR_DOMAIN_SHUTOFF =  5 : the domain is shut off
> VIR_DOMAIN_CRASHED =  6 : the domain is crashed
> }

I would say that's not a mere coincidence :)

> 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 the case of destroying a VM, that looks like it may be a
copy-paste error?

> We've also got some rather undefined semantics for a state_description over
> and above the state itself, with the state_description taking values like
> 'spawning', 'rebooting', and 'shutting_down'.  The first two are disjoint from
> the libvirt states, but the latter is a direct overlap.

Much agreed here.

> I personally don't like the libvirt states.  The name "SHUTDOWN" to mean
> "graceful shutdown requested" is very confusing (no doubt the source of some
> of the problems above).  Also, that state is guest-dependent (i.e. whether the
> VM is shutting down is dependent of the guest co-operating) whereas the other
> states are definitively about the virtualization layer.  This mix is awkward.
> Particularly weird is that the transition state "being shut down" is present,
> but the state "being rebooted" isn't.

Agreed, so do you suggest a set of flags for the state of the domain
and a set of flags for the state of the *action operating on* the
domain?

But then again, that's kind of what the state_description is being used for...

Perhaps combining the two into something like this would work?

class DomainState:
    NOSTATE = 0x00
    SPAWNING = 0x01
    RUNNING = 0x02
    BLOCKED = 0x03
    REBOOTING = 0x04
    SHUTTING_DOWN = 0x05
    PAUSED = 0x06
    SHUTDOWN = 0x07
    CRASHED = 0x08

> Also, there are states, such as "spawning" which we would like to represent,
> but can't.

Would the above solve that?

> Finally, BLOCKED is a pretty useless state -- a VM might in reality be blocked
> on some VCPUs but others, and in any case, this is always a transitory thing,
> changing on millisecond scales, and doesn't have any useful meaning in a
> remoted API.  (More useful is some statistical measurement of how long each
> VCPU has been blocked over an aggregate timescale, and in which circumstances
> they've been blocked, but that's a discussion for another time.)

++

-jay