Runtime error opening .vbox file: -102(File not found.).

[RePlay]

Hi guys,

I'm not a 100% sure what happened, but I believe what happened is that I shut down Windows while my virtual machines were still running. I probably forgot because they're headless VMs. Note that I didn't tell Windows to force close non-responsive applications.

Anyway, the error message that greets me today is this:

Runtime error opening 'C:\Users\Danio\VirtualBox VMs\Debian 7.4.0 x64 Switch 01\Debian 7.4.0 x64 Switch 01.vbox' for reading: -102(File not found.).
D:\tinderbox\win-4.3\src\VBox\Main\src-server\MachineImpl.cpp[727] (long __cdecl Machine::registeredInit(void)).
Result Code:
E_FAIL (0x80004005)
Component:
Machine
Interface:
IMachine {480cf695-2d8d-4256-9c7c-cce4184fa048}

And the following error for 3 other linked clones of the above VM:

A differencing image of snapshot {7ab9ee9a-3acc-42ff-9649-04efd3ab6f24} could not be found. Could not find an open hard disk with UUID {fb647cb8-7ca3-493a-8837-c3ba73904ad8}.
Result Code:
E_FAIL (0x80004005)
Component:
SnapshotMachine
Interface:
IMachine {480cf695-2d8d-4256-9c7c-cce4184fa048}

Here are the contents of the VM directory:

Code: Select all

 Directory of C:\Users\Danio\VirtualBox VMs\Debian 7.4.0 x64 Switch 01

26/02/2014  01:44    <DIR>          .
26/02/2014  01:44    <DIR>          ..
25/02/2014  10:14           123.053 Debian 7.4.0 x64 Switch 01.vbox-prev
26/02/2014  01:44           123.068 Debian 7.4.0 x64 Switch 01.vbox-tmp
25/02/2014  10:14    <DIR>          Logs
19/02/2014  10:05    <DIR>          Snapshots
               2 File(s)        246.121 bytes
               4 Dir(s)   9.551.339.520 bytes free

Note that the .vbox-prev file is intact. If I understand correctly this is a backup of the .vbox file. The .vbox-tmp file has a timestamp that seems to coincide with when I shut down Windows.
I'm guessing I can just rename the .vbox-prev file to .vbox and the VM should work again, but I'd prefer it if someone could confirm this for me before I start tampering with it.

Here are the contents of one of the linked clones:

Code: Select all

 Directory of C:\Users\Danio\VirtualBox VMs\Debian 7.4.0 x64 Switch 02

26/02/2014  01:44    <DIR>          .
26/02/2014  01:44    <DIR>          ..
26/02/2014  01:44            44.672 Debian 7.4.0 x64 Switch 02.vbox
25/02/2014  10:14            44.657 Debian 7.4.0 x64 Switch 02.vbox-prev
25/02/2014  10:14    <DIR>          Logs
19/02/2014  10:12    <DIR>          Snapshots
               2 File(s)         89.329 bytes
               4 Dir(s)   9.538.093.056 bytes free

The .vbox file timestamp matches that of the .vbox-tmp file from the first VM.
The .vdi file of the harddrive of the first VM is also still intact on another harddrive (since my C:\ is an SSD).
Note that I had a number of snapshots for all of my VMs (the original and the linked clones).

I found this similar thread: viewtopic.php?f=6&t=50447 (can't post the link as a new member, sorry).
But he doesn't use snapshots or linked clones, so I hope you don't mind I created a new thread for this.

I'm using VirtualBox version 4.3.6 r91406 on Windows 7, 64 bit. Thanks in advance!

[socratis]

I can just rename the .vbox-prev file to .vbox

I would copy .vbox-prev to .vbox in case something goes wrong again. But if the .vdi and its snapshots are OK, everything should work.

[RePlay]

I've gone ahead and made a full backup of everything. I then copied the .vbox-prev file to .vbox and restarted VirtualBox. And indeed, the original VM and its linked clones work again!
Thanks for your help socratis!

[mpack]

The .vbox-tmp file was actually the correct file to use. When VBox writes out a new config the steps are :-

1. Write updated config to <vmname>.vbox-tmp (any previous file of that name is overwritten). [ It's possible it does this several times over the course of a session - I've not checked. ]
2. On session close, delete <vmname>.vbox-prev.
3. Rename <vmname>.vbox to <vmname>.vbox-prev.
4. Rename <vmname>.vbox-tmp to <vmname>.vbox.

So, if VirtualBox crashes before this sequence is completed then you would prefer to recover using the -tmp file first, resorting to the -prev only if you must. In practice there will hopefully be no important changes between the -tmp and -prev copies, so getting those wrong shouldn't have any serious consequences - like losing a snapshot.

[socratis]

like losing a snapshot

Snapshots? You?

[mpack]

Not me. It's potentially an issue for the OP.

[RePlay]

A bit of a tardy reply but is it just me or are snapshots something that people tend to stay clear of around here?

[mpack]

AFAIK, none of the experienced users around here will have any truck with snapshots. Frankly, the feature exists because VMWare had them, hence if VBox didn't have them it would appear as a big red cross on a comparison table. The feature is attractive to noobs who don't understand the risk they're taking with their data - even worse, they think that snapshots are a kind of backup. Snapshots have simply never been a good idea - in VMWare or in VBox.

Anyone with an engineer's eye glances once at the obvious fragility (a house of cards structure) - and avoids them.

Anyone with experience usually ends up having or observing a catastrophe or simply finds that having snapshots around makes lots of things a pain (disk space conservation, guest compaction, guest defragmentation etc), and hence avoids them.

[socratis]

I use them on all my guests. I need the cleanest guests possible, so I make the installation, update the guest and freeze it. Once a month or so, I update this basic snapshot, install the newest guest additions (if any), and if I'm satisfied that there are no major issues, I "overwrite" my basic snapshot with the newer one. Never had a problem in the 4 years that I'm using VBox. But, I don't do nested or branched snapshots.

[mpack]

Yes, that's the typical usage scenario prior to the first disaster. IMHO: if you want a backup, make a real backup to secondary media. If it's on the same disk as the original, and there is no redundancy, and it's controlled by a single control file - a common point of failure - then it isn't a backup.

Most of the snapshot disaster stories around here are basically akin to "I was dancing along the edge of a cliff one day when...". I.e. there's almost no need to read further, the potential risk should have been obvious to anyone with eyes. The fact that it hasn't happened a particular person yet doesn't lessen the risk.

I've never heard the phrase "cleanest guest possible" used in the context of snapshots. I'm not entirely sure what it means... but if you want to preserve a minimal working set: create one, then back it up.

[socratis]

Snapshots are not used as a backup. I do have a backup of all my clients and the configuration at an external HD which exists just for this purpose. This is updated usually at every release of VBox, before I update my guest VMs with a fresh snapshot.

To me the value of snapshots is that it plays the role of Undo. I mess around, install software, change settings and then... pffft Undo (which is "Revert to the last saved snapshot"). That's all. I keep my guests clean. No additional software is installed besides the basic OS and its updates (once a month or so).

It's much quicker to revert to the last saved snapshot than restoring a backup. And by rough estimates I've done this procedure several thousands of times over the last 4 years. I'd say the odds are really good that something doesn't go wrong. But, in the case it does, there is always a backup. A proper one.

As for snapshot problems, I've seen a few people messing more often with their setup (snapshots in network shares, external HDs, non-standard locations) or having such a convoluted snapshot tree that they forgot which snapshot was which. The snapshot feature if used properly is pretty stable. I've heard your warnings and opposition many times, but I haven't seen an actual example where things went wrong due to a snapshot.

[RePlay]

It seems I've sparked an interesting discussion.

I was using snapshots in a similar manner as socratis, that is a snapshot for a clean install and then some more after installing other stuff on the VM. My snapshot tree was probably a bit too deep so I've deleted most of the snapshots since I shouldn't be needing to go back to a clean slate as I know the current setup works.

However I still need the base snapshots for my linked clones, a feature that has saved me quite a bit of space: I currently have 3 clones of my original 1.6GB VM. In total all 4 VMs use slightly above 2GB as opposed to the 6GB that would otherwise be necessary for unlinked (standalone) clones.

And of course I've made sure that I also have proper backups of the VMs now.

[mpack]

a feature that has saved me quite a bit of space: I currently have 3 clones of my original 1.6GB VM. In total all 4 VMs use slightly above 2GB as opposed to the 6GB

It's a false economy. The space argument typically only applies to child states that are effectively unused. As soon as you start using them in anger they quickly accumulate enough changes to make the starting size mostly irrelevant. And when you try to manage the disk consumption... that's when you discover the downsides: you can't easily offload to secondary storage, you can't compact, or defragment or resize.

@Socratis: if you want examples of snapshot failure you need only perform a search for the word "snapshot" on this site. I doubt anything you find will be a success story. As to whether snapshots "caused" the failure... that misses the point. The point is that the structure is inherently fragile and prone to failure (in addition to having the downsides mentioned above). The exact proximate cause of failure is not important.

[socratis]

The exact proximate cause of failure is not important.

Oh, but that's exactly the point. You can't blame snapshots just because something goes wrong in the whole scheme of things. You (of all people) would not blindingly blame the snapshot feature alone. It's a combination of things that can go wrong. Same thing with rawdisk access. If you know what you're getting yourself into, it's a welcomed feature. Otherwise you better have a whole disk backup. A proper one .

[mpack]

You are ignoring the point of my argument, which is simply that snapshots are prone to failure. The structure is not robust, leading to many failure mechanisms each of which produce catastrophic data loss unless you have real and up to date backups.

And when I say snapshots, I really mean all differencing schemes. For example, if corruption damages the base VM in a linked clone scheme, then all linked clones are lost . I don't care what caused the corruption - data loss like that is unacceptable.