virtualbox.org

I just installed Windows 7, and after reinstalling VirtualBox things got messed up. Tried changing the UUID on the base .vdi file trying to fix one problem without realizing that I was creating another problem. The snapshots are now complaining about it's parent file not having the correct UUID. So, how do I fix this?

And for the record, I really don't like the way VirtualBox handles snapshots. And, the UUID makes absolutely no sense to me either. If you could easily change it, great. But don't lock it down like this... And if I want to revert back to a previous snapshot, without killing the most recent snapshot, let me.

Anyway, how can I change the UUID back in the base .vdi file, or change the snapshot UUID to match the base UUID?

Thanks.

The only way to fix the UUIDs now, provided you know what you are doing, is with a hex editor. There are in fact two UUIDs in the base VDI that may need to be fixed - the create and modify UUIDs, both of which must match what the snapshot expects. The expected values of these UUIDs can be found in the snapshot header.

I'm curious as to what problem you thought you were fixing by changing the UUID (I assume you did it with the "internalcommands sethduuid" method). The only common reason for using the latter is after copying a VDI using the host OS: but that would mean you already had a backup copy of the affected VDI.

All of this assumes of course that you haven't already modified the contents of the base VDI. Nasty things could happen if you have.

You might try editing the VirtualBox.xml and the machine.xml files with the new UUID (after backing them up).

The UUID of the base VDI is used in the <StorageControllers...<StorageController...<AttachedDevice...<Image uuid=... section of the first snapshot in the machine xml, and also in the topmost <MediaRegistry...<HardDisks...<HardDisk uuid= section of VirtualBox.xml.

If that works, let us(me) know, because I'm not sure if the connections between base VDIs and snapshot differencing hard disks is only stored in the XML files, or is also stored elsewhere.

MarkCranness wrote:You might try editing the VirtualBox.xml and the machine.xml files with the new UUID (after backing them up).

The UUID of the base VDI is used in the <StorageControllers...<StorageController...<AttachedDevice...<Image uuid=... section of the first snapshot in the machine xml, and also in the topmost <MediaRegistry...<HardDisks...<HardDisk uuid= section of VirtualBox.xml.

If that works, let us(me) know, because I'm not sure if the connections between base VDIs and snapshot differencing hard disks is only stored in the XML files, or is also stored elsewhere.

That might be a bit of a problem, as the parent UUID the snapshot relies on is noted INSIDE the snapshot, not just the VM XML file.

MarkCranness wrote:If that works, let us(me) know, because I'm not sure if the connections between base VDIs and snapshot differencing hard disks is only stored in the XML files, or is also stored elsewhere.

They are stored in the VDI headers, as I mentioned in my message. That is after all why the "internalcommands sethduuid" command exists: to modify a VDI header. All the xml file does is associate media files with a VM, and filenames with UUIDs. Editing the xml would likely put a final nail in the coffin.

mpack wrote:I'm curious as to what problem you thought you were fixing by changing the UUID (I assume you did it with the "internalcommands sethduuid" method). The only common reason for using the latter is after copying a VDI using the host OS: but that would mean you already had a backup copy of the affected VDI.

Some good news, I was able to recover the base .vdi file from the original hard drive it came from. The bad news is that the snapshot was not recoverable. And what I had copied originally is now gone too. So, I'm screwed...

The reason I did the "internalcommands sethduuid" option is because I had not copied the virtualbox.xml file. I was trying to get those in sync, when I should have copied it as well. I have done this before when I copied a VM to another machine. The problem is, the last VM I did this to didn't have any snapshots. This one did...

This really shouldn't be this hard. I should be able to copy the VDI files, point virtualbox to it, and then it just work. All of these UUIDs do nothing but complicate things. I'm sure there are very good reasons for having UUIDs, but it's not working for me. I like supporting open source, but I'm seriously considering going back to VMware.

mpack wrote:They are stored in the VDI headers, as I mentioned in my message. That is after all why the "internalcommands sethduuid" command exists: to modify a VDI header. All the xml file does is associate media files with a VM, and filenames with UUIDs. Editing the xml would likely put a final nail in the coffin.

Actually, editing the xml file is easy. It's the UUIDs in the .vdi files that are hard. If all of those match, I can edit the xml file to match. No big deal there. But really, all the xml file should do is point to the files themselves, and leave out the UUIDs. And the .vdi files should point to each other some other way. And I should be able to tell virtualbox that the snapshot is correct. And if I do the "internalcommands sethduuid" command, it should automatically change the snapshots to match. But editing the xml file isn't a nail in the coffin.

rmorgan wrote:Actually, editing the xml file is easy.

Actually, I didn't say it wasn't easy, I said it would be the final nail in the coffin. I.e. most likely make matters (perhaps terminally) worse. Making matters worse is often easy!

Sasquatch wrote:That might be a bit of a problem, as the parent UUID the snapshot relies on is noted INSIDE the snapshot, not just the VM XML file.

(Looks about...) Yes, I see VDI, VHD and VMDK headers store the parent UUID (and iSCSI and RAW do not).
And code checks that the UUID of the parent (according to VirtualBox.xml?) must match that stored in the header, so my suggestion to rmorgan would have failed.

mpack wrote:They are stored in the VDI headers, as I mentioned in my message.

I saw that and understood you to mean that the headers self-referentially-store the UUID of image itself. But I wondered if the headers also store the UUID of their parent, or of their children, but was not clear enough.