Falsche childuuid im snapshot nach virtualBox Frei

[klemenso]

Hi Leute,
wir nutzen VirtualBox um einen Ubuntu Server auf Windows zu hosten. Beim löschen eines Snapshots hat sich allerdings VirtualBox heute aufgehängt, wir mussten VirtualBox zum runterfahren zwingen und nun können wir den Server nicht mehr starten.

Fehlermeldung:

Für die virtuelle Maschine FMS19 (Ubuntu 18.04) konnte keine neue Sitzung eröffnet werden.
Could not open the medium 'C:\Path\VirtualBox VMs\FMS19 (Ubuntu 18.04)\Snapshots/{e11f9da2-5a70-4f2a-bb85-911fab5e59ee}.vdi'.
VD: error VERR_FILE_NOT_FOUND opening image file 'C:\Path\VirtualBox VMs\FMS19 (Ubuntu 18.04)\Snapshots/{e11f9da2-5a70-4f2a-bb85-911fab5e59ee}.vdi' (VERR_FILE_NOT_FOUND).
Fehlercode:
E_FAIL (0x80004005)
Komponente:
MediumWrap
Interface:
IMedium {ad47ad09-787b-44ab-b343-a082a3f2dfb1}


Wir haben den Command "vboxmanage showhdinfo" genutzt um herauszufinden ob alle uuid's noch korrekt angegeben sind und uns ist aufgefallen, dass der neuste Snapshot eine "child uuid" besitzt ({e11f9da2-5a70-4f2a-bb85-911fab5e59ee}.vdi'). Diesen VDI file gibt es allerdings nicht.
Es gibt im Manual leider keinen Befehl, wie z.B. setchilduuid, sodass man die ID löschen könnte.
Im vBox file steht ebenfalls eine falsche HardDisk:

<HardDisks>
<HardDisk uuid="{b24cbe63-1c82-4252-a866-096c881a9015}" location="FMS19 (Ubuntu 18.04)-disk001.vdi" format="vdi" type="Normal">
<HardDisk uuid="{3fa2a1c9-8d68-4931-a967-144d0009d2f1}" location="Snapshots/{3fa2a1c9-8d68-4931-a967-144d0009d2f1}.vdi" format="vdi">
<HardDisk uuid="{078e5a03-3d77-449d-9764-e926bfc50ca8}" location="Snapshots/{078e5a03-3d77-449d-9764-e926bfc50ca8}.vdi" format="vdi">
<HardDisk uuid="{fc689173-47a5-48b6-b894-2becd38c99c5}" location="Snapshots/{fc689173-47a5-48b6-b894-2becd38c99c5}.vdi" format="vdi">
<HardDisk uuid="{e11f9da2-5a70-4f2a-bb85-911fab5e59ee}" location="Snapshots/{e11f9da2-5a70-4f2a-bb85-911fab5e59ee}.vdi" format="vdi"/>
</HardDisk>
</HardDisk>
</HardDisk>
</HardDisk>
</HardDisks>

Dies kann man zwar sehr einfach raus editieren, es löst das Problem aber nicht.

Habt ihr vielleicht eine Idee wie wir das lösen können? Wir brauchen sehr dingend eine Lösung, denn es hängen hunderte Stunden an Arbeit an diesem Server, bzw an den Files darauf.

[scottgus1]

Habt ihr vielleicht eine Idee wie wir das lösen können? Wir brauchen sehr dingend eine Lösung, denn es hängen hunderte Stunden an Arbeit an diesem Server, bzw an den Files darauf.

The easiest answer to this question is to restore the entire VM from your backups. Important data will be backed up by your IT personnel in a tested restorable method.

The error says the file can't be found, and that probably comes from this:

Beim löschen eines Snapshots hat sich allerdings VirtualBox heute aufgehängt, wir mussten VirtualBox zum runterfahren zwingen und nun können wir den Server nicht mehr starten.

The process that was "deleting" the snapshot was killed off before it could complete editing the .vbox file, possibly before it could complete "deleting" the snapshot.

"Deleting" a snapshot only means to "delete" the ability to "go back in time" in the VM's history to that point. Deleting actually involves back-porting all the data in the snapshot to the previous parent disk file. So a killed snapshot "delete" also includes the possibility of a partially corrupted parent disk as well as an inaccurate .vbox configuration file.

Even if we manually edit the .vbox file to remove the partially deleted snapshot, there is no guarantee that the parent disk will be usable.

What made you think the process was hung?

If you don't have backups of this important VM, then you might get a new VM without snapshots by using Mpack's CloneVDI to make a flattened clone of the final snapshot disk you still have. Instructions to do this are in the CloneVDI folder.

[klemenso]

Hello scottgus1,
thank you very much for your reply.

The easiest answer to this question is to restore the entire VM from your backups. Important data will be backed up by your IT personnel in a tested restorable method.

Unfortunately, our only backup method is these snapshots. A disgustingly large mistake, as we have now learned.

Fortunately, we were able to create a linked clone of the VM that we could launch and extract all the files we needed from. I think we were incredibly lucky that the file was not corrupted.

What made you think the process was hung?

VirtualBox was not responding to anything we did, and after waiting about 20 minutes, we assumed that VirtualBox had frozen.

Thanks again for your answer.

[scottgus1]

Unfortunately, our only backup method is these snapshots. A disgustingly large mistake, as we have now learned.

That's quite an oops! Glad you got your files out!

Please be aware that snapshots aren't backups. They're rather like Windows System Restore points. They do make a VM more delicate, and if something glitches during a delete/merge, the VM can be hosed.

Best practice is not to use snapshots except on experimental VMs and data.

Backups best practices are:
1. Shut down the VM completely from within the VM's OS (not save-state), then copy the VM folder and all disk files residing outside the folder to 2 or more backup media, with a file-compare to confirm backup integrity.
2. Live backups using 3rd-party compatible backup software inside the VM OS and saving the backups out to backup media through a network.

Please also note that the linked clone VM is also based on the snapshot system that exists in the original VM and can also break in a host glitch. The linked clone also requires the presence of the original VM & snapshot files to run. It's quite a house of cards now. It would be good to use CloneVDI to try to flatten all those snapshots to a new single drive file and build a new VM around it, or copy all data out of the linked clone using 3rd-party imaging software to a new VM, then not use snapshots anymore and use proper backup methods instead.