Clone vs. Snapshot vs. Copy-a-Folder

[DashingDave]

With regard to options for
a. cloning a VM
b. taking snapshots
c. simply copying the VM's folder (containing the .vdi & .vbox files) to another location,

I'm a bit confused on what the advantages are of using one "backup" method when compared to the others. e.g. a linked clone seems to have a lot in common with snapshots.

Why/when should I choose one option over the others? What's the primary goal of each method?

Sincerely,
He-who-is-a-newbie-and-has-already-screwed-up-and-trashed-more-VMs-than-he-hasn't-and-is-worried-that-Microsoft-and-Apple-are-going-to-think-I'm-installing-their-OSs-on-a-new-device-every-two-days....

[socratis]

First of all, out of the three solutions you proposed, only one is a backup; copying the whole folder someplace else. With that in mind, here's a summary of what each feature does:

• Cloning: Create a "really close" to the original copy. By really close I mean identical on the surface, but under the hood the UUIDs of the HDs and the VM change, the MAC addresses of the network cards change. If the OS you're cloning depends on one of these features (Windows for activation, GRUB for booting, etc.) then you might have problems down the road. The reason they change? So that you can run the original and the clone in VirtualBox. And if there's one thing that VirtualBox hates is identical UUIDs.
• Snapshots: They are really a point in time. You take a snapshot for example right before you attempt something that might "destroy" your guest. Say I want to test this shady program. Take a snapshot, test it, revert to snapshot. Nothing happened. Of course people get carried away and think that it's a backup, and they take snapshot, after snapshot, after snapshot, ending in a big messy pile of snapshots (I think 174 was the max I've ever seen). One of them goes bad? Goodbye VM. A lot of people use cloning for those purposes as well. The difference between the two tests is that with snapshots you can choose to keep the changes by merging the snapshot.
• Copying: This is a true backup of the guest and the only one qualifying as such. Correct thinking about copying the whole folder and not just the VDIs. Now, since the UUIDs (and everything else) is the same as the original, if you try to register and run the copy in VirtualBox, you'll get a big, fat failure. You have to unregister (and maybe delete?) the original and then register and run the copy.

I use all three of them:

• Copying of course for backups.
• Cloning if I want to quickly test a feature for which I don't care about, like having two virtual screens on two monitors or see if the mini toolbar looks ugly if it's on the top, or mostly for helping other users, and I don't want to mess with the original. Usually I pick a guest that is small in size (like FreeDOS), because it makes it faster.
• Finally, snapshots, I live a breathe by, but with ONLY ONE SNAPSHOT. I take a snapshot of a guest. Then say a new VirtualBox version comes out. I test the guests and if they don't work or something breaks, I revert to the snapshot. Or a new Service_Pack/OSX_Update/Linux_kernel comes out and I want to test it. If it doesn't work I revert and start searching for a solution. Now, once I'm happy with the changes, I merge them in my base and continue with my one, minimal, "empty" snapshot. Also quick and dirty let's-try-this feature.

has-already-screwed-up-and-trashed-more-VMs-than-he-hasn't

Excellent! That's the only way to learn! Oh, if I only had a cent for every VM that I've ever created, I would be on permanent vacation...

PS. Looking at your profile, I saw that you had another post, which I might have missed. I'm taking this opportunity to reply in the thread, that you asked your question (bout OSX clients in the 5.x series).

[scottgus1]

Socratis has given a very comprehensive list there of the differences between the methods. I'll just add that copying*, being a bit-for-bit copy, you can do a file compare on the copied files to confirm that the backup is an exact error-free copy and thus a true backup. And you can also file-compare the restore to confirm it's a good restore. (*see Moving a VM and re-interpret it as "Backing Up a VM")

Restoring a copy-style backup is as simple as just re-copying the files back to the original place they were. If you still have the bunged-up original, you just copy the files back over the original, don't re-register the guest, just start it up. There should be no errors.

If you don't have the original guest, or care to unregister the original guest, and your guest folder was in the usual Virtualbox format (the guest .vbox file, and the guest virtual disk, and the guest Logs and Snapshots folders all in the one guest folder) then you're free to put the restored guest anywhere you want then re-register it and start it.

FWIW, the copy method will leave you a still-activated restore, since all the UUIDs and therefore all the Windows activation test's hardware calculations will come out the same and stay activated.

[DashingDave]

• Copying: This is a true backup of the guest and the only one qualifying as such. Correct thinking about copying the whole folder and not just the VDIs. Now, since the UUIDs (and everything else) is the same as the original, if you try to register and run the copy in VirtualBox, you'll get a big, fat failure. You have to unregister (and maybe delete?) the original and then register and run the copy.

Thanks for the helpful clarifications, @socratis!

And, just to make sure I'm interpreting things correctly, does "register"/"unregister" mean to "Add... [VM]"/"Remove... [VM]" (from the GUI's Machine menu, for example)?

[socratis]

Yes. Add=Register, Remove=Unregister.
It always has to be from within VirtualBox Manager (or the command line, advanced), because VirtualBox keeps a registry of known VMs. So, never assume that if you add a VM_Folder from Windows Explorer that VirtualBox will know about it, or if you delete a VM_Folder from Windows Explorer that VirtualBox will forget about it. Unless you completely understand how the whole concept works.

[DashingDave]

FWIW, the copy method will leave you a still-activated restore, since all the UUIDs and therefore all the Windows activation test's hardware calculations will come out the same and stay activated.

I've read through the manual for mentions of cloning and UUID, but I'm not uber-familiar with Windows activations (Macs, I know; PCs, not so much). I only have 1 retail WinXP license/product key (which I presume can only be activated on one device at a time); if I activate that on a VM and then clone the VM, does the clone's different UUID make whatever-magical-Microsoft-server-that-monitors-such-things think that I've just tried to activate it on a second device? Or is the activation just tied to my (host) Mac's ID--as long as that clone is run on the same Mac as the original, Microsoft sees it as still being the same device the activation was already tied to?

[socratis]

which I presume can only be activated on one device at a time

I fixed it for you.

does the clone's different UUID ... think that I've just tried to activate it on a second device?

Yes. Actually to be more accurate, it may vary by the Windows version, and I'm not 100% sure if that's the case for XP. For more information see: Which changes trigger reactivation in a Windows guest?

Or is the activation just tied to my (host) Mac's ID

Windows XP hasn't the faintest idea it's running on a Mac, so no, that doesn't count.

For more information you could contact Microsoft, since they are the ones that know the ins and outs of their licensing scheme.

[mpack]

XP's activation mechanism is different from that used by later Windows versions. While it won't know anything about Macs, it will be sensitive to a change of CPU, if the VM is ever moved to a different host. All of the other signatures move with the VM, so provided you move the VM as a unit, retaining e.g. MAC address and minor weighted elements such as RAM size then the VM will remain activated.

Win7 activation is sensitive to the motherboard signature (a.k.a. VM UUID), hence cloning the VM will deactivate it. Not so with XP. Note that the VM UUID is distinct from disk UUID. I don't think the latter matters for any Windows version.

[scottgus1]

I vaguely recall that there may be a way to fake the "motherboard" UUID that Virtualbox reports to the guest OS so cloning & such may not cause reactivation. The manual, section 8.8, reports that this command:

Code: Select all

VBoxManage modifyvm --hardwareuuid <original-machine-uuid>

should do it.

[mpack]

Well, that isn't "faking" a signature as such, it's just setting a signature explicitly instead of letting VirtualBox select a default. The default is the same as the VM UUID, but yes you can override the default.

... actually, I've been meaning to confirm if the devs ever fixed a bug in that area, which I reported but they didn't seem to understand the report. The bug was that it wouldn't let you set an explicit motherboard signature which was the same as the default one. So, you had to clone the VM, and then you could change the signature to match the old VM. Thereafter you can clone it as many times as you like.