deleting snapshot hangs

[koshimagap]

Tried upgrading host to latest release VirtualBox v.4.3.14-95030 (from earlier upgrade to VirtualBox v.4.3.12 from initial install of VirtualBox v.4.3.6) as noted in post chain below as noteirak had suggested.

VirtualBox-4.3.14-95030-Win.exe upgrade install downloaded from https://www.virtualbox.org/wiki/Downloads/ website appeared to run as expected without error, however when attempting to launch the VirtualBox application it crashes (see attached screenshot) Any feedback as to what may be going wrong and how to fix would be greatly appreciated.

[socratis]

Yes, but that may be a different problem altogether. See the sticky at the top of the forum. Try the suggested test builds and see if that resolves it. But, that may be a total different issue from your original problem, so don't go crazy on this one...

[koshimagap]

socratis yes, do realize VirtualBox v.4.3.14 crash problem is unrelated to original deleting snapshot problem, but opted to add issue to this post chain as upgrading VBox was only remaining suggestion hoping it includes fixes that happen to address original deleting snapshot problem. Since cannot run latest release version, cannot test if upgrading VBox happens to fix deleting snapshot problem.

Thanks though for link to VBox v.4.3.14 issue showing others encountering problems running this version.

[mpack]

Please keep to one issue per topic. Off topic discussion may be deleted, especially when it duplicates discussion already going on elsewhere.

[koshimagap]

Followup to unresolved problem deleting snapshot...

Have tried upgrading host to latest VirtualBox v.4.3.16-95972 just released but with same result when attempting to delete snapshot -- deletion appears to run as expected until dialog status reaches 9% at which time process seems to hang (status percentage no longer increments beyond 9% but time remaining increments indefinitely, and constant HDD activity drops off to only intermittent activity)

Attached is .zip of VBoxSVC.log file.

[VBonUbuntu]

A follow-up on this for all who are stuck in related situations after deleting / merging snapshots.

Last week I deleted an older snapshot (S2 of S1-S5), merging took some time and froze at 99%. After hours I turned off, saw no chance of finishing. And btw there was plenty of disk space available. If this is a bug, I don't know. Consequently afterwards the VM didn't want to start anymore and I panicked.

After a lot of google-searching and investigation in the config files I did this (surprisingly simple):
* Open the XML-config of the VM (.vbox)
* There I found two references to the snapshot S 2 (in UUID syntax...)
** One in a hierarchy-tree like in the snapshot-GUI, just a one-liner
** One deeper down in the config (the snapshot with many preferences occurred in a cascade of all the snapshots)
* I deleted both. For latter content, I had to be careful to delete the whole block of this snapshot as well as the closing lines (</Snapshot> and </Snapshots> or other way round) furhter down the file.

Afterwards everything was fine. Can't guarantee that this will work if merging hangs at 10% or 20%, maybe then there actually ARE inconsistencies of all the incremental "delta-information" of the snapshots. But in my case VirtualBox in the first place simply did not want to start the VM because it THOUGHT something essential is missing. Now everything seems to work to fine. I guess the merging had been complete but for some case froze.

Hope this is helpful for some users.

[mpack]

The "one liner" is almost certainly where the snapshot VDI was associated with a disk controller. By deleting that line you disconnect the drive from the VM, though it's still registered. Deleting from the media registry (the hierarchical list) unregistered the snapshot, though the parent elements of that drive are still present.

It is really highly unrecommended that people mess with .vbox files, especially complex snapshotted ones, when they don't have a good idea of what they're doing.

[VBonUbuntu]

The "one liner" is almost certainly where the snapshot VDI was associated with a disk controller. By deleting that line you disconnect the drive from the VM, though it's still registered. Deleting from the media registry (the hierarchical list) unregistered the snapshot, though the parent elements of that drive are still present.

It is really highly unrecommended that people mess with .vbox files, especially complex snapshotted ones, when they don't have a good idea of what they're doing.

Good point. Of course people should only start this kind of fumbling around when they are either (a) fully aware of what they are doing or (b) totally desperate as I was, with the prospect of having lost the whole VM-scenario. And for (b) of course it is wiser to first backup (the corrupt scenario) and then try this kind of repairing.

Regarding the "one liner": I will post more details which lines I have modified, just don't have it at hand right now.

[mpack]

And for (b) of course it is wiser to first backup (the corrupt scenario) and then try this kind of repairing.

Yes, if you really must do this, then make a backup before you start, so at least things shouldn't get any worse - and keep the backup around for a while, because fumbling can create damage that isn't instantly obvious.

[VBonUbuntu]

and keep the backup around for a while, because fumbling can create damage that isn't instantly obvious.

Question regarding this: Which is the best way to check the integrity of the file system as a whole (the combination of original vdi + snapshots + sav-files) to find potential inconsistencies due to failed snapshot-merge:
* Checking from within the guest, i.e. with typical tools from the guest OS
* or some kind of checking "a layer below", potentially with VirtualBox management tools at the host?

[mpack]

You can't always check for the "damage". For example if you restore the wrong state then you'll still end up with a completely self consistent state, but it may be missing a lot of data. All you can do is look for the stuff that's most important to you, and of course a filesystem check can't hurt.

[CurtisForrester]

I realize this is an old thread, but FWIW I saw the state stuck in "

Code: Select all

DeletingSnapshot - MachineState(21)

after deleting a snapshot. Plenty of disk space, no corruption and the snapshot had actually been successfully deleted. (Verified with inspecting the machine's ".vbox" file and looking into the ./Snapshots folder for the UUID).

All I needed to do was close VirtualBox - on the Mac I also had to use Acvitity Monitor to kill the "VBoxSVC" and "VBoxXPCOMIPCD" services. Upon restarting VirtualBox the machines now correctly showed them as "Saved" state.