After deleting snapshot Windows 7 guest status = inaccessibe

[joesyn1]

Hi, thanks for your help in advance,

I have a Windows 7 guest running on Mac OS 10.x. It was fine until I removed a snapshot. After I restarted virtualbox, the machine is inaccessible and gives the following error message:

Hard disk '/Users/jgrange/VirtualBox VMs/JGG_VM_Win7/JGG_VM_Win7.vmdk' with UUID {76c5b5be-7fc5-4604-b1c0-dce60a4f5b90} is already attached to the virtual machine 'JGG_VM_Win7' ('/Users/jgrange/VirtualBox VMs/JGG_VM_Win7/JGG_VM_Win7.vbox').
Result Code: NS_ERROR_FAILURE (0x80004005)
Component: SnapshotMachine
Interface: IMachine {480cf695-2d8d-4256-9c7c-cce4184fa048}

I have attached the current .vbox and log files as a zip files as well as the log file from when I deleted the snapshot.

Thanks again!

[mpack]

Moved to "OS X hosts" since your question doesn't relate to your Windows guest.

How exactly did you "remove a snapshot", and did you do anything else to the VM, such as detach or reattach the main VMDK? Anything else iffy that you might have done?

It might help if you posted a screenshot showing the contents of the VM and "Snapshots" subfolders, I need to see all file details if possible (i.e. name, size in bytes).

The error message is very odd: I'd expect you to get that message if you tried to add a hard disk using the Storage panel - I can't see any reason for you to get that message when launching the VM, assuming that's what you tried to do (you don't explicitly mention the circumstances in which the error is seen).

[joesyn1]

Thanks for the reply.

I selected snapshots for the Windows 7 guest machine, selected a snapshot, and selected Delete snapshot. I did however delete a snapshot several levels "up the chain" - e.g. not the most recent one, the one before it in this case (see screenshot as an example).

And no, I did not do anything else to the VM.

The error is displayed as soon I start up Virtualbox.

I have attached screenshots of the "broken" guest machine, the other working VMs, and the contents of the VM and snapshot subfolders.

Thanks for your help in advance!

[mpack]

Well, that's a right mess you have there.

It's clear that you originally had two hdd chains, each of 3 elements. The control information for both chains has been reduced to two elements, but the two chains have been mixed together (broken) in the remaining snapshot state (the foreground state looks fine).

I could repair the control information, but I see that all 6 file fragments are still in their expected places, so I have no idea what's in them.

I think only salvage is practical at this point - and it's a pity you're on a Mac, since the only repair tool is CloneVDI - a Windows host app. However, it will run under Wine/WineBottler etc.

1. You need to use CloneVDI to clone the newest snapshots in each chain: that would appear to be "{bcef....}.vmdk" (primary chain) and "{c39d4...}.vmdk" (HD1 chain). If it works then it gives you two merged VDIs.
2. Create (BUT DO NOT RUN) a new VM, attaching the cloned VDIs. Move the VDIs into the new VM folder before attaching them.
3. Unregister the old AND the new VMs, then manually edit the machine UUID on the second line of the new VM's .vbox file. Change the new UUID field to "{8743d88e-d3d4-4850-8f0a-e14ef0ad13f6}". This step is necessary to avoid have to reactivate Win7.
4. You can now register the new VM using Machine|Add..., and run it.
5. Avoid snapshots in future, instead make real backups of the VM folder.

[joesyn1]

Thanks very much for the help!

So, just to make sure I'm clear-

1) Are you saying that the snapshots feature in this environment (Mac OS host, Windows guest) is not a reliable way to capture changes in the guest machine state and I should back up the VM folder instead?
2) Is this a bug that will be fixed in a future release since having the ability to use snapshots as a way to manage various machine states is incredibly useful.
3) In Step 3, you say unregister the old and new VMs- are you talking about license management in Windows or is this a process within VirtualBox?

Thanks again for all your help, much appreciated!

[loukingjr]

2) Is this a bug that will be fixed in a future release since having the ability to use snapshots as a way to manage various machine states is incredibly useful.

Personally I've never understood how managing various machine states is "incredibly useful" but that is just me. For one thing they can take up a large amount of HD space. For another, I wouldn't be able to remember which previous state I want to return to.

[joesyn1]

Hi,

My use case is hosting a variety of different releases of specific applications since I am a consultant and support clients who run a lot of different versions of the applications we support/market and it's helpful to be able to spin up a snapshot that matches their environment in order to either troubleshoot an issue or model a solution.

I'm careful about how I name my snapshots to be able to "remember" what the individual config is.

I agree about the HD space limitations though, but I generally don't keep more than half a dozen snapshots at any given time and I don't load anything on the guest that I absolutely don't need. But more hard drive space is always better

[loukingjr]

That actually makes sense. One in the useful column.

[mpack]

1) Are you saying that the snapshots feature in this environment (Mac OS host, Windows guest) is not a reliable way to capture changes in the guest machine state

There is no problem with that, however users - for some strange reason - seem to believe that snapshots also somehow preserve the host state, which is absolutely not the case. Here it was the host which screwed up, not the guest - so by rights you should have lost the lot, since you don't seem to have taken any host backups.

Personally I have no use for snapshots. If I want to preserve a VM state I back up the host side - which has the incidental affect of fully backing up the guest state as well, plus it doesn't waste disk space on keeping all guest states online at once, which I simply don't need. Nor does it encourage me into the bad habit of deleting stored states to recover disk space.

[joesyn1]

I admit, I'm a little confused here.

I was deleting a guest snapshot, I wasn't making any changes to the host unless you are saying that deleting a guest snapshot = performing an operation on the host.

The host didn't crash or do anything to indicate there was an issue. I got the usual merging files/images message and the process completed without any error messages.

And if I backup my host folder anytime I want to make a change to a guest machine, how does that save me disk space since I'm presumably making a copy of the entire host folder rather than just capturing the changes on a individual guest image. I suppose if I didn't want to keep the previous system states I would simply delete the old copy of the host folder, but for me, I need to retain that information.

And why is it a bad habit to use the snapshot management tools since they are part of the product feature set? Are you saying that there are some known problems or just that it does not fit your individual computing style?

I realize you did use the word "personally" but since you are a forum moderator, I'm assuming you are speaking from a position of experience dealing with these kinds of issues.

I want to use the product the way it was meant to be used and avoid these issues in the future so if your advice is avoid creating guest snapshots, I suppose I will have to change my procedures.

[mpack]

The effects may be noticed inside the guest, but deleting a snapshot involves manipulation of files on the host filesystem, not the guest filesystem. Had you been doing something inside the guest that you needed to undo then yes, snapshots can do that. What snapshots can't do is undo filesystem changes on the host.

Snapshots are not host backups. Proper backups can do both jobs, as already mentioned.

Snapshots exist as a feature because the competition has them, hence users expect it. Like many products, if certain features are not implemented then the software will not even be considered in certain shortlists, magazine review articles etc. However that doesn't mean that every feature that exists is a good idea. Indeed anyone with an engineering mentality will take one glance at the snapshots feature and recognize it as a fragile house of cards. And not just on VirtualBox - the fragility is inherent in the concept.

Do I really need to explain how backups save disk space? Of course in absolute terms they do not - however backups can be stored on secondary media, which effectively has infinite capacity and hence absolute space is not an issue. Backups do save disk space on your local drive(s).

Please take a moment to consider the issues before commenting further, and ideally do some research (i.e. search the forums). I and others have explained these matters many times previously, and I admit that I get quite testy when asked to explain it yet again. In fact you might find it an eye opener to Google for "snapshot problem site:forums.virtualbox.org".


One final way to think of it: if you use snapshots you still have to make host backups. But, if you have host backups then you don't need snapshots.