My position is that if DMTF already provides a life-cycle model, we should adopt it as long as it meets the requirements from use cases. Regards -- Ignacio M. Llorente, Full Professor (Catedratico): web http://dsa-research.org/llorente and blog http://imllorente.dsa-research.org/ DSA Research Group: web http://dsa-research.org and blog http://blog.dsa-research.org Globus GridWay Metascheduler: http://www.GridWay.org OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org On 17/04/2009, at 16:21, Andre Merzky wrote:
Quoting [Lars Larsson] (Apr 17 2009):
On Fri, 17 Apr 2009, Ignacio Martin Llorente wrote:
We do not need "migrated", that is an internal operation that can not be requested using a Cloud API
I fully agree with Ignacio.
I think there is a difference between the set of states that a VM can be in, and the set of states that may be set using the API. The first set may be larger and include informational states such as "being migrated" or "being copied", but that does not mean that the user can actively request that a VM should be migrated.
Yes, I agree with that: active versus informational states. Again, other state models in OGF represent such information as substates, e.g. 'Migrating' might be expressed as a substate of 'Running'. I am not saying this is how this group should do state modeling, just for information...
I suggest that we use the states shown at page 25 in "CIM System Virtualization White Paper" by the DMTF (DSP2013), available here:
http://www.dmtf.org/standards/published_documents/DSP2013_1.0.0.pdf
That is an interesting model - it seems a lot of people have been thinking hard about that :-) I like it...
To play the devils advocate though:
- Is that state model suitable for our use cases? It seems to allow for quite a large number of transissions, but is missing the 'Initial -> Suspended' transition which has been discussed on this list earlier.
- The design seems to have been motivated by physical states rather than logical states (the power state notes are an artifact of that I guess?). Are the states applicable to our use cases?
- Do we need a distinction between 'VS State' and 'Enabled State'? The document says: " the EnabledState property represents the virtual system’s state" - so, what is the difference to VS state, which is, I take, also the virtual system state? The document does not offer a better definition/distinction AFICS.
Displaying extra information, such as "being migrated" or "being copied" is up to the infrastructure provider to optionally add to the description of the state that is reported via monitoring.
+1
Best, Andre.
-- Nothing is ever easy.