Mailing List Archive

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.

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?

Ewan.

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

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.

Current xm tools also document another state 'crashed' although I've not
actually seen it in practice I assume it can happen if the PV guest kernel
panics.

Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

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

On Wed, Aug 23, 2006 at 11:26:00PM +0100, Daniel P. Berrange 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.
>
> Current xm tools also document another state 'crashed' although I've not
> actually seen it in practice I assume it can happen if the PV guest kernel
> panics.

Good point, yes. You've probably never seen it because the guest only
ends up like that if the on_crash=preserve flag is set, otherwise the
guest will be cleaned up automatically by Xend (unless of course you've
never crashed a guest, but I don't believe that for a second ;-)

You're right that this is another state that we ought to include.

Thanks,

Ewan.

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

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@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

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@novell.c
Sent by: Ewan Mellor <ewan@xensource.com>
xen-api-bounces@l cc
ists.xensource.co Xen-API
m <xen-api@lists.xensource.com>
Subject
Re: [Xen-API] Additional vm power
08/23/06 03:57 PM 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@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

> 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@novell.c
Sent by: Ewan Mellor <ewan@xensource.com>
xen-api-bounces@l cc
ists.xensource.co Xen-API
m <xen-api@lists.xensource.com>
Subject
Re: [Xen-API] Additional vm power
08/23/06 03:57 PM 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@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api