Using older copies of VDI file

[wearyofallthiscrap]

So I've gotten an interesting problem dumped into my lap.

A well-meaning but inexperienced colleague has a very simple VB setup. One host, one guest, one VDI. His backup scheme has been to make a copy of the VDI file periodically, whenever the guest is in powered-off state. Unfortunately, he did the copying using standard host copy methods, not any kind of VDI-aware cloning.

Now there's something on his current guest that's been lost or misconfigured or some such; details weren't given but they don't really matter. Rather than replace the entire guest disk image, he wants to (A) attach an older image to the guest, and then (B) inside the guest, mount that disk at some temporary mount point and go copy individual bits off of it. More specifically, he wants to do these steps repeatedly to get varying files out of VDIs of varying ages.

(B) wouldn't be a problem, we've all done that before. But of course he can't get (A) done because trying to attach any of the older copies gives the error "Cannot register the hard disk 'older_copy.vdi' {foo-bar-baz} because a hard disk 'current.vdi' with UUID {foo-bar-baz} already exists." No surprises there. This is when he came to me. (Filenames replaced for easy reading.)

My thought was to clone the copied files, and then attach the clones. But "VBoxManage clonehd older_copy.vdi clone_of_older_copy.vdi" fails with the same error message. Apparently even command-line cloning involves a registration step, which I wasn't expecting. And we can't use the Virtual Media Manager UI because that doesn't even list the copied files, only the currently attached ones.

What are his options here? All I can come up with is:
1) Remove the guest VM entirely from the VB Manager, carefully NOT deleting any files.
2) Using "VBoxManage clonehd", clone each of the older VDI files that he wants to examine.
3) Re-add the guest VM into the VB Manager.
4) Attach/delete each of the clone images as needed.

Is there a better approach?

(At the very least, I've convinced him to stop making VDI backups using file copy operations. He's learning a lot!)

[noteirak]

There is definitly a better approach to avoid all this duplication and wasted space & time!

~$ vboxmanage internalcommands
Oracle VM VirtualBox Command Line Management Interface Version 4.2.8
(C) 2005-2013 Oracle Corporation
All rights reserved.

Usage: VBoxManage internalcommands <command> [command arguments]

Commands:

[...]

sethduuid <filepath> [<uuid>]
Assigns a new UUID to the given image file. This way, multiple copies
of a container can be registered.

[...]

WARNING: This is a development tool and shall only be used to analyse
problems. It is completely unsupported and will change in
incompatible ways without warning.

This is what you're searching for to solve your case. Do this on all the old backup VDIs, and you'll be able to add them. Please note the part I've emphasis in red!

[mpack]

Your friend's simple approach to backups is actually IMHO the correct approach, except that I would backup the entire VM folder, rather than just the VDI. He should not allow himself to be talked into forms of backup that involve modifying the backup (and hence making it not a true 1:1 replacement), including exporting or normal cloning.

As Noteirak says, the sethduuid command can be used to easily change the UUID field in the VDI header.

[wearyofallthiscrap]

Your friend's simple approach to backups is actually IMHO the correct approach, except that I would backup the entire VM folder, rather than just the VDI. He should not allow himself to be talked into forms of backup that involve modifying the backup (and hence making it not a true 1:1 replacement), including exporting or normal cloning.

That's what I used to do myself; entire VM folder copies with a datestamp. Except then it wasn't possible to use the older VMs without removing the current one from the VB Manager due to the same duplicate-UUID error, even though the VMs containing the duplicate drives were themselves completely separate. This was in 4.1.something, if that's changed then it's great news.

After my VB setup stabilized, I moved to doing backups from within the guest, which gives me more granular control without having to worry about UUIDs at all. It's more effort but more reward. Occasionally I still do "external" backups of the VM folder, but I don't rely on them exclusively. I think my colleague will probably do the same, once he and his group figure out exactly what operating system they want to run as a guest... I overheard one of his coworkers proposing OS/2 Warp in order to support some really old software, I think merely hearing those words took five years off his life.

As Noteirak says, the sethduuid command can be used to easily change the UUID field in the VDI header.

Definitely doing that instead, thanks to you both!

-T

[Perryg]

Guests created prior to version 4.0 of VirtualBox the entire backup process was a lot different. While you could backup the VDI file you had to be sure to shut everything down and then replace the corrupt file with the one from backup. Since the UUID was the same the only thing you loose is exactly what you loose when restoring ( a full restore ) from a normal backup. The problem with this is say you have a corrupt program inside the guest you are forced to replace the entire build back in time and not just the faulty portion. That is still true today and why you should have a separate data structure and back it up as you would on metal. The only real benefit as I see it with the folder structure in => 4.0 is the portability. You can move the guests around easier and more reliably. You also have the sense of security in knowing that the control files are all backed up too, which is another plus in my book.

Also throw in the snapshots which I don't use and the process gets even more delicate in the older version than the current folder structure.

[mpack]

After my VB setup stabilized, I moved to doing backups from within the guest

If that means e.g., copying files to a shared folder from within the guest, then yes that should work very well too, as would imaging the guest drive from inside the guest (which would preserve the guest filesystem metadata, partition maps etc). Still, the option I described earlier is IMHO the simplest, most complete backup.

ps. If you want to have two copies of a VM then cloning is the answer. Temporarily unregistering the old, conflicting VM resolves the conflicts until the clone is made.

[JASD]

I'm trying to use the command "sethduuid" on my VirtualBox 4.2.12 and its not working. Did they change the command name? Any other solutions to change the UUID?

Thanks!

[mpack]

It's "VBoxManage internalcommands sethduuid", as it has always been. This command is officially undocumented, but I don't expect it's going to get deleted any time soon.

ps. I deleted your cross post.