Easy Cloning

[mpack]

I think your treatment of option 2 is a bit unfair. If your intention was to compare snapshots with cloning, then your option 2 doesn't seem to describe a reasonable implementation of cloning.

"Backup Machine Directory and VDIs", I'm not entirely sure what you mean by that, but if cloning was offered in a more convenient fashion you wouldn't copy entire folders, you would just copy two or three files from one folder to another (either manually or by clicking a button). If we assume that dynamic VDIs are no more than a few GB then it shouldn't take more than a few minutes for the copy. Call it ten minutes.

At the revert stage you have "restore machine directory". In fact there is nothing to restore in option 2 - you simply delete the cloned files, which takes no more than a second or two.

Then there's the bit in the middle, the actual "test and use" time.

First, I'd suggest that creating a VM that you are only going to keep around for 3 minutes is an unusual requirement. Mine will tend to be around for days at least (in fact, so far I've not deleted any clone), so the difference between a creation time of seconds and a creation time of minutes is really neither here nor there.

Secondly, no offence, but I suspect that your thinking on this is too heavily influenced by the current VBox design: "make and revert" is VBox snapshot thinking, based on the assumption that you can only have one snapshot instance in use at a time, an assumption which is true of snapshots, not true of clones. If instead machine A was your original base, and B was a clone created in order to test changes then in most circumstances you would only create B once, you would use it for multiple tests, not deleting it afterwards. You would only delete and recreate when you have specific reasons to doubt the test otherwise. Reversion is not necessary simply to return to point A: A and B are fully independent entities, so you can resume using A whenever you want. Ditto for B. There is no real "revert" operation with clones.

The problem isn't snapshot; it's the paucity of VBox support utilities for them...
But that paucity is at least partly due to the complex nature of snapshot chains, making programmers naturally reluctant to do anything too fancy with them.

[TerryE]

Maybe we are talking at cross purposes. I originally made the statement in response to your

I can't say that I see much need for snapshots. It seems to me that they are essentially a space saving feature, ie. it lets you have two or more VMs in which the bulk of their disk space usage resides in a common VDI.

Yes, snapshot are a barrier to cloning. I am not arguing on that point, but the point I am making is that they do have there uses and my example was just a case where they are extremely useful, and yes this is nothing to with cloning.

If you take the case of a LAMP stack holding a copy of this forum with a back-end database. OK the VDIs do only total 3Gb or so. If I am experimenting with some phpBB fix, I want to post a few transactions and put in some Q&D diagnostics, but when I'm done, then I want to back all that crap out. Snapshots are just a significantly easier way of doing this than backups.

I don't want to fall out over this Let's just agree to differ

[mpack]

First I'll tackle this.

I don't want to fall out over this Let's just agree to differ

There's absolutely no danger of that. I respect your opinion and I respect the work you do on this site. I'm just trying to convince you of the error of your ways regarding snapshots!

Maybe we are talking at cross purposes. I originally made the statement in response to your

I can't say that I see much need for snapshots. It seems to me that they are essentially a space saving feature, ie. it lets you have two or more VMs in which the bulk of their disk space usage resides in a common VDI.

It's possible we are at cross purposes - I said before that I wasn't altogether sure what you had in mind with your "option 2". What I was responding to was your objection to my suggestion that snapshots were primarily a space saving device, having no other advantage relative to cloning. In the case of your LAMP stack example, my alternative would be to create a clone containing the current phpBB code - you could then fiddle with it to your hearts desire. If it now does something you like you call the new clone the live system, if not you delete it. So the snapshot didn't do anything you couldn't have done with a clone, the snapshot was just created a bit faster, deleted a bit slower - but mainly it just took less disk space. The convenience of it is simply because the GUI makes snapshots convenient, it could make cloning equally convenient.

OTOH, there are lots of things that you can do with clones that you can't easily do with snapshots. Movement between PCs for example.

I guess if people want the space saving advantages of snapshots I'm not going to say they can't have it. I just think cloning should have been a primary supported model as well. Since I've been whinging about this since joining the forum I guess you could say this is my main issue with VBox.

[mpack]

Maybe we are talking at cross purposes.

And I just realised why that might be. When I said before that snapshots were primarily a space saving feature I meant relative to an equivalently implemented cloning feature, but didn't actually say so because I felt that was implicit in the topic name. Sorry if this created confusion.

[Micheus]

Very interesting discussion for a beginner like me- thanks.

The user interface is always a little bit behind on supporting all VBox features. In the future there will be full cloning support including VM configuration etc. This is when the user interface will get a menu entry for this. (ref. post)

while the future not coming...

http://www.murga-linux.com/puppy/viewtopic.php?t=21796

This tells you how to change the annoying UUID. Specifically:

VBoxManage internalcommands setvdiuuid disk2.vdi

I have updated the vBoxManageGUI in order to add an option to use this method...

...and I have observed that the time spent by both of methods is very similar. So, maybe the clonevdi option just do this two steps automatically. Is it true?

[mpack]

So, maybe the clonevdi option just do this two steps automatically. Is it true?

I'm not sure which two steps you are referring to. "clonevdi" copies the VDI and changes the UUID. "internalcommands setvdiuuid" changes the UUID of an existing VDI. Neither clones the VM settings file, so the user has to recreate the VM manually - which leads to several beginner errors (eg. accidentally changing the hardware in a significant way).

I hear that Sun are worker on a simpler cloning method, eg. a button in the GUI similar to the snapshot button. Hopefully they'll allow for greater mobility of the clones too, between PCs.

[Micheus]

I'm not sure which two steps you are referring to. "clonevdi" copies the VDI and changes the UUID.

Exactly these two.

Using internalcommands setvdiuuid I need first to copy source vdi file to an other (new name) and execute vboxmanage with this option. At this point is more simple (and logical) to use clonevdi options.
So, I have updated our vBoxManageGUI without necessity.

Neither clones the VM settings file, so the user has to recreate the VM manually - which leads to several beginner errors.

like me.


Thanks again for your explanation.

[gstark45]

I have a vdi called "xp test" (note the space between xp and test) that works wonderfully, and I'd like to clone. After discovering and agreeing with the many people here who don't like how Virtual Box handles, this, I got my path set and proceeded to try a clone, but vboxmanage clonevdi doesn't like that space in the name, mentioned above. Is there an easy way to rename the vdi so that "xp test" can be "xptest" and not mess up the vdi in the process. a simple rename may fix this, but will that have any effect on its registration, etc. Need some advice.....

[mpack]

but vboxmanage clonevdi doesn't like that space in the name.

Have you tried wrapping "xp test" in quotes on the vboxmanage command line, just as you did here? I've not tried it, but that's the usual way to deal with spaces in filenames.

[TerryE]

Do a VBoxManage list vms, and pick out the UUID for test xp, then use that. I've noticed that VBoxManage sometimes has difficulty in handling spaces in vm names etc. However it parses the UUIDs fine, and you can use the UUID instead of the symbolic name.

[gstark45]

I understood the instructions about using vboxmanage list vms, but I also have snapshots, so should I be looking at the uuid's for the lastest snapshot, or for the vm itself.? Thanks for your help by the way...

Greg

[TerryE]

VBox doesn't currently allow you to clone VDIs which have snapshots. Some of us would say that that's a pretty strong functional hole, but that's the way it is. The only supported way is to delete all intermediate snapshots so you are only left with the one version that you want and then you can clone that. Sorry.

[gstark45]

crap...that is definitely a problem, cause I don't want to loose the snapshots either...

thanks anyway...

.gs.

[gstark45]

are you saying that I can delete all but the snapshot I want, and then clone that...if that will work then I can live with that...

.gs.

[TerryE]

Yes. The safest way is to use the GUI. If you have the space then back up the machine directory, the VDIs and the VirtualBox.xml registry, just in case you make a mistake. If not then be very careful.