IMHO I think "migrating" and/or "migrated" are states that doesn't make sense under the point of view of a Cloud API, this should be something internal completely transparent to the user. Also, I am not sure that we need the "copied" state. What does it mean exactly? Aside from that I kind of like the model. I would suggest adding a "suspending" state (or "saving" since it presumabley the VM is going to dump a snapshot) and also a "finished" state and "failed" state to handle errors. What do you think? On Fri, Apr 17, 2009 at 3:14 PM, Lars Larsson <larsson@cs.umu.se> wrote:
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.
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
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.
Best regards,
-- Lars _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Constantino Vázquez, Grid Technology Engineer/Researcher: http://www.dsa-research.org/tinova DSA Research Group: http://dsa-research.org Globus GridWay Metascheduler: http://www.GridWay.org OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org