[Solved] Error VERR_FILE_NOT_FOUND after deleting the oldest snapshot

[Batiskaf]

Hello,

Some time ago I've deleted the oldest snapshot to free some space... All runs smoothly for weeks until I shutdown the host (correctly). And now when I start the VM I get:

Code: Select all

VBoxHeadless --startvm MTS
Oracle VM VirtualBox Headless Interface 6.0.24
(C) 2008-2020 Oracle Corporation
All rights reserved.

Error: failed to start machine. Error message: Could not open the medium '/home/oleg/VirtualBox VMs/MTS/Snapshots/{435449d1-1eb7-40d2-b73a-29ec9d4b66c6}.vdi'.
VD: error VERR_FILE_NOT_FOUND opening image file '/home/oleg/VirtualBox VMs/MTS/Snapshots/{435449d1-1eb7-40d2-b73a-29ec9d4b66c6}.vdi' (VERR_FILE_NOT_FOUND)

The host is Debian 10 64bit, the Guest is Windows 7 32bit.

Code: Select all

VBoxManage showvminfo MTS
..
..
Snapshots:

   Name: Снимок 1 (UUID: f5054709-32c0-4fb6-964b-19dd6255b596)
   Description:
Activate + VirtualBox Guest Addititions
      Name: Снимок 2 (UUID: 6551605a-72a0-4e3c-9d63-a085d17203f3)
      Description:
Перед созданием второй машины
         Name: Снимок 3 (UUID: c686dca8-d36e-4f98-aff8-c05ddb530ef7) *
         Description:
Текущий снимок

Code: Select all

ls -hal VirtualBox\ VMs/MTS/Snapshots/
total 59G
drwx------ 2 oleg oleg 4,0K дек  9 16:55 .
drwxr-x--- 4 oleg oleg 4,0K мар  9 16:24 ..
-rw------- 1 oleg oleg 350M окт 24  2015 2015-10-24T18-42-59-575016000Z.sav
-rw------- 1 oleg oleg  33G мар  6 22:29 {b3c31086-354a-41ba-82cb-9c5a34a38932}.vdi
-rw------- 1 oleg oleg  26G фев 25  2017 {b60af860-12b2-4e5e-bf4e-46bc0b239d02}.vdi

I don't quite understand - the file {435449d1-1eb7-40d2-b73a-29ec9d4b66c6}.vdi isn't even listed in snapshots (showvminfo result). I shutdowned the VM MTS correctly before shutdown the host.
Please help me to restore the VM or at least to get some files from it. Some information has no backups since the beginning of January(((

[mpack]

How did you "delete the oldest snapshot"? If you did it by deleting files using the host OS then the VM will need to be restored from a backup.

[Batiskaf]

How did you "delete the oldest snapshot"? If you did it by deleting files using the host OS then the VM will need to be restored from a backup.

Yes, I deleted file in OS.
Could you tell me how to restore VM from backup using a command line (I don't have GUI on the host)?

[scottgus1]

Yes, I deleted file in OS.

That's a killer. Snapshots are incremental, parts of a chain, and are not able to be deleted in the OS file manager if you still want a working VM. They must be deleted inside Virtualbox. And snapshots are not backups, BTW.

Restoring this file is not something Virtualbox can do. You'll have to find it in your backups and copy it back to the stated path in the error message. How to copy files from one place to another in your host's command line would be the subject of a web-search.

[Batiskaf]

Yes, I deleted file in OS.

That's a killer. Snapshots are incremental, parts of a chain, and are not able to be deleted in the OS file manager if you still want a working VM. They must be deleted inside Virtualbox. And snapshots are not backups, BTW.

Restoring this file is not something Virtualbox can do. You'll have to find it in your backups and copy it back to the stated path in the error message. How to copy files from one place to another in your host's command line would be the subject of a web-search.

I do not have *.vdi backups. I only have backups of some important data from the guest system. Unfortunately, they are too old.
Is there no way to extract the files from the main disk file MTS.vdi and the remaining snapshots?
The files are as follows:
MTS.vdi - 40GB
{b3c31086-354a-41ba-82cb-9c5a34a38932}.vdi - 33GB
{b60af860-12b2-4e5e-bf4e-46bc0b239d02}.vdi - 26GB.
Isn't that too excessive for a 40GB-guest-drive?

[mpack]

The files are as follows:
MTS.vdi - 40GB
{b3c31086-354a-41ba-82cb-9c5a34a38932}.vdi - 33GB
{b60af860-12b2-4e5e-bf4e-46bc0b239d02}.vdi - 26GB.
Isn't that too excessive for a 40GB-guest-drive?

An individual snapshot stores all the sectors that have changed, relative to the previous frozen state, since that snapshot was created. If you change all the sectors then one snapshot can grow to be the size of the disk - 40GB in your case. If you have 5 snapshots and they all grew to max size for some reason then that requires 40*5=200GB disk space. No, this is not excessive: you told it to preserve 5 states each consisting of 40GB of data, so it's only doing what you said.

Experienced users do not use snapshots. We preserve states by backing the VM folder up to offline storage.

Note mention of the previous state. That means that each snapshot requires the previous state to to be present to fill in areas of the disk not yet written in the latest state. The previous snapshot in turn depends on the snapshot before that, and so on back to the base VDI.

So, the worst thing you could do is to delete the base disk. The next worst thing you could do is delete the oldest snapshot - which is what you say you did. That means that all snapshots newer than the one you deleted have no previous state for reference.

This HAS ALREADY caused catastrophic data loss. There is no way to recover that data loss without backups. What we cannot yet know is how much the later states depended on the lost data.

There is a good possibility that you can hack the chain of VDIs to obtain a chain that VirtualBox will accept (i.e. no missing elements). Note however that the drive will still be corrupted and the exact extent of that corruption can't be predicted. I'll do a new post to give advice on the hacking part.

[mpack]

If you want to hack your VDI chain, first make a backup of the VM folder so things can't get any worse.

Next, create a spreadsheet which lists all of the VDI filenames involved, then for each VDI file use VBoxManage to get it's linkage which you'll add as columns "UUID" and "Parent UUID" to the spreadsheet. E.g.

Code: Select all

VBoxManage showmediuminfo <vdi name>

For each VDI that gives you something like this:

Capture.PNG (21.67 KiB) Viewed 17545 times

The lines that interests you are the "UUID" and "parent UUID" lines. That tells you the UUID of this VDI and also what previous state (parent) UUID it requires to be present. Since I don't use snapshots all of my linkage reports will have "base" in the parent UUID line.

You should soon be able to sort the spreadsheet into linkage order and it will also be clear which UUID is missing. Your list will be like this (I'm using A, B, C as standins for the unwieldy UUIDs which are long numbers - I also omitted the filename column).

A <base>
B <missing>
C <depends on B>
D <depends on C>

The hack is to tell VBoxManage to replace the parent UUID link in C so that it refers to A instead of B. That is done using a call "VBoxManage internalcommands sethdparentuuid <vdi filename C> <uuid A>". The UUID should be in the same format normally used to display UUIDs in VirtualBox. Use showmediuminfo to confirm that the change took.

NOTE: while this removes the broken reference from the VDI chain, the .vbox file still contains many references to the missing file so the broken VM still will not start. So, what you need to do next is to clone the newest snapshot (i.e. "D" from the list above), this will create a new merged VDI which you can build a new VM around.

I say again that this will only stop VirtualBox from complaining about the lost data. Whether there is enough data left to allow boot and recovery remains to be seen.

[fth0]

a new merged VDI which you can build a new VM around.

I say again that this will only stop VirtualBox from complaining about the lost data. Whether there is enough data left to allow boot and recovery remains to be seen.

One possible strategy is to create a new VM and add this merged VDI file, which will most probably contain a corrupted file system, as a secondary virtual disk image to the VM. Afterwards, you can run any disk repair or disk recovery software on this VM.

[mpack]

For completeness it should also be mentioned that you can immediately mount the base VDI in another VM, and that will give access to all the files in the oldest state. This is a worst case outcome and may be better than having nothing at all. But, given the size of the individual snapshots I imagine that each was run for quite a while before the next was created, so the oldest state could be very old.

[Batiskaf]

Thanks a lot guys! I very appreciate your help!
For this moment.
I've tried to attach the base MTS.vdi to another VM. It has no useful data - only clean OS((
I stuck at 2 problems:
1. I've run the command "VBoxManage internalcommands sethdparentuuid <snapshot 2> <uuid MTS.vdi>". There was no errors. But "showmediuminfo" shows old parent UUID (snapshot 1) as nothing changed((
2. Please tell me how to make this part:

So, what you need to do next is to clone the newest snapshot (i.e. "D" from the list above), this will create a new merged VDI which you can build a new VM around.

[mpack]

1. I've run the command "VBoxManage internalcommands sethdparentuuid <snapshot 2> <uuid MTS.vdi>". There was no errors. But "showmediuminfo" shows old parent UUID (snapshot 1) as nothing changed((

Two possibilities: (1) VirtualBox sometimes caches drive information in a background task in memory, you need to give it 30 seconds to unload before checking "showmediuminfo". Or (2) you entered the command wrong: please show us the exact command you typed.

2. Please tell me how to make this part:

So, what you need to do next is to clone the newest snapshot (i.e. "D" from the list above)

"VBoxManage clonemedium <filename of snapshot vdi D> <output vdi name>" ought to work I think. I'm not entirely sure as I typically use CloneVDI for this kind of work, but for you that probably adds an unnecessary complication seeing as you're using a Linux host (CloneVDI is a Win32 app).

[Batiskaf]

1. I've run the command "VBoxManage internalcommands sethdparentuuid <snapshot 2> <uuid MTS.vdi>". There was no errors. But "showmediuminfo" shows old parent UUID (snapshot 1) as nothing changed((

Two possibilities: (1) VirtualBox sometimes caches drive information in a background task in memory, you need to give it 30 seconds to unload before checking "showmediuminfo". Or (2) you entered the command wrong: please show us the exact command you typed.

I've given it time, I even rebooted host PC - all the same.

This is my chain of snapshots:

Code: Select all

VBoxManage showmediuminfo ~/VirtualBox\ VMs/MTS/MTS.vdi
UUID:           a6585b65-1ccd-4a18-821b-de181b640d11
Parent UUID:    base
State:          created
Type:           normal (base)
Location:       /home/oleg/VirtualBox VMs/MTS/MTS.vdi
Storage format: VDI
Format variant: fixed default
Capacity:       40960 MBytes
Size on disk:   40962 MBytes
Encryption:     disabled
In use by VMs:  MTS (UUID: 615e74a6-12d0-4098-92d0-2ef693e23335) [Снимок 1 (UUID: f5054709-32c0-4fb6-964b-19dd6255b596)]
Child UUIDs:    435449d1-1eb7-40d2-b73a-29ec9d4b66c6

VBoxManage showmediuminfo Snapshots/{435449d1-1eb7-40d2-b73a-29ec9d4b66c6}.vdi
UUID:           435449d1-1eb7-40d2-b73a-29ec9d4b66c6
Parent UUID:    a6585b65-1ccd-4a18-821b-de181b640d11
State:          inaccessible
Access Error:   Could not open the medium '/home/oleg/VirtualBox VMs/MTS/Snapshots/{435449d1-1eb7-40d2-b73a-29ec9d4b66c6}.vdi'.
VD: error VERR_FILE_NOT_FOUND opening image file '/home/oleg/VirtualBox VMs/MTS/Snapshots/{435449d1-1eb7-40d2-b73a-29ec9d4b66c6}.vdi' (VERR_FILE_NOT_FOUND)
Type:           normal (differencing)
Auto-Reset:     off
Location:       /home/oleg/VirtualBox VMs/MTS/Snapshots/{435449d1-1eb7-40d2-b73a-29ec9d4b66c6}.vdi
Storage format: VDI
Format variant: dynamic default
Capacity:       0 MBytes
Size on disk:   0 MBytes
Encryption:     disabled
In use by VMs:  MTS (UUID: 615e74a6-12d0-4098-92d0-2ef693e23335) [Снимок 2 (UUID: 6551605a-72a0-4e3c-9d63-a085d17203f3)]
Child UUIDs:    b60af860-12b2-4e5e-bf4e-46bc0b239d02

VBoxManage showmediuminfo Snapshots/{b60af860-12b2-4e5e-bf4e-46bc0b239d02}.vdi
UUID:           b60af860-12b2-4e5e-bf4e-46bc0b239d02
Parent UUID:    435449d1-1eb7-40d2-b73a-29ec9d4b66c6
State:          created
Type:           normal (differencing)
Auto-Reset:     off
Location:       /home/oleg/VirtualBox VMs/MTS/Snapshots/{b60af860-12b2-4e5e-bf4e-46bc0b239d02}.vdi
Storage format: VDI
Format variant: differencing default
Capacity:       40960 MBytes
Size on disk:   25876 MBytes
Encryption:     disabled
In use by VMs:  MTS (UUID: 615e74a6-12d0-4098-92d0-2ef693e23335) [Снимок 3 (UUID: c686dca8-d36e-4f98-aff8-c05ddb530ef7)]
Child UUIDs:    b3c31086-354a-41ba-82cb-9c5a34a38932

I run the command:

Code: Select all

VBoxManage internalcommands sethdparentuuid Snapshots/\{b60af860-12b2-4e5e-bf4e-46bc0b239d02\}.vdi a6585b65-1ccd-4a18-821b-de181b640d11
UUID changed to: a6585b65-1ccd-4a18-821b-de181b640d11

And the last portion of showmediuminfo shows the same, as if nothing had changed.

[mpack]

Try wrapping the a6585.... UUID in braces { like so }. I think you should also wrap all command line arguments in quotes "like so" if the field contains anything potentially risky, e.g. minus signs that might be seen as options.

That said, VBoxManage appears to confirm that it made the change...

Perhaps you should switch to using CloneVDI to view the headers of VDI files. It surprised me that you were able to show medium info for the missing file, this implies that it fetches this information from the .vbox file, and not from the VDI header. But it's the info from the VDI header that we need. CloneVDI will run under Wine on Linux hosts, and is definitely not taking information from .vbox files.

Also, your "VDI chain" appears to be incomplete. There is at least one snapshot VDI to follow. Perhaps you only intended to show a relevant portion.

[Batiskaf]

I tried all the combination of braces with path to the snapshot and UUID. The command showmediainfo shows the same. But the command internalcommands dumphdinfo does.

Code: Select all

VBoxManage internalcommands dumphdinfo "Snapshots/{b60af860-12b2-4e5e-bf4e-46bc0b239d02}.vdi" --- Dumping VD Disk, Images=1
Dumping VD image "Snapshots/{b60af860-12b2-4e5e-bf4e-46bc0b239d02}.vdi" (Backend=VDI)
Dumping VDI image "Snapshots/{b60af860-12b2-4e5e-bf4e-46bc0b239d02}.vdi" mode=r/o uOpenFlags=9 File=0x0056000b1fc070
Header: Version=00010001 Type=4 Flags=0 Size=42949672960
Header: cbBlock=1048576 cbBlockExtra=0 cBlocks=40960 cBlocksAllocated=25874
Header: offBlocks=1048576 offData=2097152
Header: Geometry: C/H/S=1024/255/63 cbSector=512
Header: uuidCreation={b60af860-12b2-4e5e-bf4e-46bc0b239d02}
Header: uuidModification={c62118cc-2f68-4619-a150-19ff81935749}
Header: uuidParent={a6585b65-1ccd-4a18-821b-de181b640d11}
Header: uuidParentModification={7693a8b7-8d7a-4502-bc17-654132223465}
Image:  fFlags=00020000 offStartBlocks=1048576 offStartData=2097152
Image:  uBlockMask=000FFFFF cbTotalBlockData=1048576 uShiftOffset2Index=20 offStartBlockData=0

But then I got stuck.
I tried to clone the newest snapshot:

Code: Select all

VBoxManage clonemedium "Snapshots/{b3c31086-354a-41ba-82cb-9c5a34a38932}.vdi" MTS_new.vdi
VBoxManage: error: Parent medium with UUID {b60af860-12b2-4e5e-bf4e-46bc0b239d02} of the medium '/home/oleg/VirtualBox VMs/MTS/Snapshots/{b3c31086-354a-41ba-82cb-9c5a34a38932}.vdi' is not found in the media registry ('/home/oleg/.config/VirtualBox/VirtualBox.xml')
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component MediumWrap, interface IMedium, callee nsISupports
VBoxManage: error: Context: "OpenMedium(Bstr(pszFilenameOrUuid).raw(), enmDevType, enmAccessMode, fForceNewUuidOnOpen, pMedium.asOutParam())" at line 191 of file VBoxManageDisk.cpp

I tried to edit MTS.vbox file, '/home/oleg/.config/VirtualBox/VirtualBox.xml', clonemedium didn't work.
After editing MTS.vbox file (deleting the line about the missing snapshot) I tried to start the VM. There was an error. After that the VM "MTS" disappeared. The VirtualBox show only UUID in the list of VMs

For now i'm cloning the newest snapshot with the CloneVDI under Windows. I'll see what it brings.

Also, your "VDI chain" appears to be incomplete. There is at least one snapshot VDI to follow. Perhaps you only intended to show a relevant portion.

Yes, I didn't post the output about the newest snapshot.

[mpack]

Editing a .vbox file referencing multiple snapshots would be tricky. The old VM is dead and gone, you shouldn't complicate matters by continuing to try to use it. The goal here is to create a merged clone of the most recent state and then mount the merged VDI in another VM, either as the boot disk or as a secondary disk if you can't get it to boot.

CloneVDI should be able to clone the most recent snapshot if you first put all all of the remaining VDI files (including the base) in a single folder. CloneVDI makes no use of .vbox files so doesn't care what they contain. It works purely from the UUID links.