Hi Randy, First of all, excuse me for the delayed answer. This thread somehow ended up in my Trash folder, not really sure why (?). Comments interspersed, On Sun, May 10, 2009 at 12:10 AM, Randy Bias <randyb@gogrid.com> wrote:
First off, we've got to be careful about saying 'copy the image'. You probably mean 'copy the instance'. Where an image is an on-disk representation of an unpowered VM and an instance is a running version of that same on-disk representation or a running copy.
So for 'cloning' do you mean:
- An image in a library is turned into an instance? - A running instance is copied? - If a running instance is copied do you have a new image or a new instance? - If you have a new instance, is it powered on automatically? - Does a new cloned instance have the exact same hardware profile as the original cloned instance? RAM, CPU, disk? - Does a cloned instance also duplicate the RAM?
I really mean copy the image, as it is a suggestion for an attribute of the "Drive" object. AFAIK, the clone attribute has been already suggested for the "Server" object (BTW, wouldn't it be better to call it VirtualMachine instead of Server?). So, as I see it Drive object -> clone attribute. Set to yes: "Copy the on-disk representation of one drive of a VM" Set to no: "Use the original on-disk representation of one drive of a VM" As I see it , one VM can have more than one drive, it is not its complete representation (I mean, it can be, but it doesn't have to). I suggested it because I can see the benefits of declaring the base system drive of a VM as cloneable (so it can be used by different VMs) but each VM having their data partition set as not clonable and each VM use their own one (not sure if we should introduce the concept of "shareable", it is quite a dangerous field). And other combination also. The cloning attribute for "Servers" has to be correctly defined, and I suggest using your questions as a starting point to unequivocally do so. It just got me thinking, VMWare uses the concept of Template aside from the VirtualMachine, with the purpose of making clones. How do you feel about this?
In other words, am I making a PURE 100% duplicated running instance (there are use cases for this), a new reference image, or am I 'scaling' an instance (either horizontally with more copies or vertically with a bigger copy)?
In this case, I guess I was talking about a new reference image.
I've seen clone used by customers, clouds, and various IT departments and I've almost never seen the same definition. It's about as bad as 'cloud' when it comes to being defined.
I understand you concern. I think that the purpose of this working group is to precisely define these concepts, as good as we can do i. I really think that the "clone" attribute for drives is a good complement for the "persistent" one.
When our customers ask for cloning they also usually mean very different things.
Precisely, we have to give them meaning as what we find more reasonable.
I'd rather have a few different verbs here that specified different behavior and that's potentially a rat's nest because not every cloud supports all of these behaviors.
That is true, I suggest using it as a extension. We will therefore avoid further ill-defined "clone" attributes for different clouds. That is, IMHO, what standards are for.
--Randy
Thanks, I think this is a rather productive discussion. - Tino
On 5/7/09 12:44 AM, "Tino Vazquez" <tinova@fdi.ucm.es> wrote:
Hi Randy,
By "clone" I mean "copy the image" if set to yes or "use the original" if set to no. What other meaning do you have in mind?
Also, for me "stop" means stop the VM and dump the state onto a file. "suspend" would be stop it but keep the state in memory.
BTW, there is something in state machine diagram [1] that I still don't understand. The entry point (after start) I take it as the "defined" or "pending" state. If that is correct, then we have our VMs going always from the initial state to "suspended". Is that what we want?
Regards,
-Tino
[1]
http://forge.gridforum.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/StateMode> l
-- 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
On Thu, May 7, 2009 at 1:29 AM, Randy Bias <randyb@gogrid.com> wrote:
dange
-- Randy Bias, VP Technology Strategy, GoGrid randyb@gogrid.com, (415) 939-8507 [mobile] BLOG: http://neotactics.com/blog, TWITTER: twitter.com/randybias