Re: [Xen-API] Additional vm power state values

[Gareth S Bestor <bestor@xxxxxxxxxx>]

> Regardless of what we call it, I'm happy with the transition states being in
> that field along with the "steady" states.  It is important to note that in
> some cases the client may not see the transition state -- the guest may seem
> to have atomically shifted from Halted to Running without going through
> Activating, for example.  As long as this is understood and documented
> behavior, I don't see this as a problem though.

Actually, on the CIM side of things, EnabledState transitions are initiated by a RequentStateChange() method which,
among other things, takes in the desired target state you'd finally like to get to. So the fact that a DomU might non-deterministically
and/or momentarily pass through some transient states doesn't really matter, since the CIM client is implicitly going to be waiting till the desired
target state is reached (or they get an error back).

Aside: the fact that some of the EnabledStates themselves could be transient - eg "Starting" - begs the question what happens
if you give that as the state you want the DomU to go to!?

[answer: only the 'steady' states are valid values for the RequestStateChange(uint16 RequestedState) parameter :-)]

- Gareth

Jim Fehlig <jfehlig@xxxxxxxxxx>

Jim Fehlig <jfehlig@xxxxxxxxxx>
Sent by: xen-api-bounces@xxxxxxxxxxxxxxxxxxx

08/23/06 03:57 PM

To	Ewan Mellor <ewan@xxxxxxxxxxxxx>
cc	Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
Subject	Re: [Xen-API] Additional vm power state values

Ewan Mellor wrote:
> On Mon, Aug 21, 2006 at 03:48:45PM -0600, Jim Fehlig wrote:
>
>   
>> Currently vm_power_state enumeration contains Halted, Paused, Running, 
>> Suspended, ShuttingDown, and Unknown values.  Since ShuttingDown is in 
>> the list can we add Activating, Suspending, (Migrating?)?  I point out 
>> ShuttingDown because it, like the proposed additions, indicate that a 
>> state transition is in progress.  I don't consider them vm power states 
>> so perhaps they should be defined separately.
>>     
>
> Yes, you're right that it is inconsistent at the moment.  After an awful lot
> of argument with folks here, we've come to the conclusion that we _should_
> include those transition states as well.  You're right that they're not really
> power states, but then John Levon complained about that name too -- perhaps
> his suggestion of 'run state' would be better?  IIRC, the CIM VirtualSystem
> profile is going to reuse the core PowerState, so perhaps we can put up with
> the odd naming too.
>   

PowerState is optional.  EnabledState is the preferred property used to 
reflect this information.   FYI, currently defined values are:
 
Unknown, Other, Enabled, Disabled, Shutting Down, Not Applicable, 
Enabled but Offline, In Test, Deferred, Quiesce, Starting

> Regardless of what we call it, I'm happy with the transition states being in
> that field along with the "steady" states.  It is important to note that in
> some cases the client may not see the transition state -- the guest may seem
> to have atomically shifted from Halted to Running without going through
> Activating, for example.  As long as this is understood and documented
> behaviour, I don't see this as a problem though.
>
> How does that sound?
>   

Sounds good :-)

Jim


_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api