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

[Gareth S Bestor <bestor@xxxxxxxxxx>]

Yeah - as Jim states, the PowerState stuff is optional, and in the DMTF System Virtualization model we're more following and implementing the EnabledState transitions instead. Regrettably, the larger DMTF CIM model today has a handful of slightly different - but to the first order of approximation, equivalent - 'state' properties sprinkled among various separately evolved class profiles, which can make strict interoperability between profiles a little difficult at times. To make matters somewhat worse, none of them have a particularly good set of state names IMO.

Personally, I would probably recommended you come up with a good, rich, meaningful set of states for Xen virtual machines that would make sense to most (non-CIM) virtualization applications, and let us take care of shoe-horning them into CIM's somewhat amenic and obscure current EnabledStates! :-)

- 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