virtualbox.org

Hallo,

I've recently deleted some of the snapshots to gain some free space on hdd drive and after that turned a pc off.
After a while I was going to turn the vm on, but have noticed, that my vm is broken.
Virtual Media Manager shows much more snapshots, as I would expect, and most of them are reported to be missing. It looks like I haven't deleted any of the snapshots. The root is "Working_Station_Win7.vdi" and has ID {828e2020-6074-4c2f-869f-568f082e1467}
The Snapshot {3fa06d56-1df0-4682-b390-57e5b1126b81} shows {db214abf-e195-4200-b92b-cb16be150583} as its parent in the Virtual Media Manager, but the CloneVDI HeaderInfo shows, that the parent of it is the root image {828e2020-6074-4c2f-869f-568f082e1467}.
See second screenshot .

The same seems to be the case for the remaining snapshots. All the missing screenshots seem to be the deleted ones.

I have no idea how could it happen, but I would really appreciate some help in restoring the VMs.
The VM been broken is a Win7 Professional OEM, migrated to Win10 during the gratis upgrade action. Unfortunately I have no other backups of the Win10 VM other than these Snapshots on my linux btrfs raid1 volume (it is on the subvolume that is not covered by the btrfs snapshotting ).

Best Regards,
Konstantin

Prepare yourself: I think those VMs are dead.

KonstantinT wrote:I've recently deleted some of the snapshots to gain some free space

If you did this in the File Manager folder, then the only recovery is to put the files back.

KonstantinT wrote:I have no other backups of the Win10 VM other than these Snapshots

Snapshots aren't backups. They are not stand-alone full disk images. They are point-in-time markers like Windows System Restore points. Each snapshot disk file is part of a chain of data that must remain complete to get the data out. Delete one disk file from File Manager and all the data thereafter is orphaned.

Deleting snapshots in the main Virtualbox window is allowable, because Virtualbox merges the data in the chains into the parent disks. (Computers being what they are, glitches can happen, and a full host backup is always wise.)

I've only used delete snapshot function from the virtualbox snapshots view.
That's clear, that it shouldn't be done via OS file manager.

Please reboot the host (or stop anything VirtualBox related and wait for 5 seconds) and provide the global configuration file VirtualBox.xml (probably ~/.config/VirtualBox/VirtualBox.xml), which could contain an optional MediaRegistry section, and the VM configuration file Working_Station_Win7.vbox, which contains two important hierarchies: A MediaRegistry section and nested Snapshot sections. Additionally, provide the output of VBoxManage list hdds.

KonstantinT wrote:That's clear, that it shouldn't be done via OS file manager.

Quite correct, and yet the forum is replete with those who did not see that point of clarity.

Your first screenshot shows a lot of missing disks that Virtualbox still expects to find. So Virtualbox's records still have these files recorded in its database, which would not be the case if the "Snapshot Delete" command in the main Virtualbox window were successfully used. Once official Delete is used, the entry for the disk in the database is purged. It is rarely possible that a glitch in the host PC occurred and prevented Virtualbox from removing one of those files from the database, but not a whole swath of them. The screenshot shows circumstantial evidence of a lot of disk files being deleted outside of Virtualbox's purview. Of course, circumstantial evidence can be pointed a different way when further evidence is provided.

It could be possible that some other software interfered with Virtualbox's Delete command and removed the files without allowing the database to be updated, or there is a new bug in Virtualbox. However, such a software interference would be a new development not known by me.

If the data was merged properly, 'vboxmanage showmediuminfo drive:\path\to\{3fa06...}.vdi' should show "Working_Station_Win7.vdi's UUID as the parent, and {91396...}.vdi's UUID as the child. 'vboxmanage showmediuminfo drive:\path\to\{e63b39...}.vdi should also show "Working_Station_Win7.vdi's UUID as the parent, and {f50ca8...}.vdi's UUID as the child. If these command fail to show the correct UUIDs as parent & child, then the chain is broken and the full set of data cannot be recovered. It is possible that the working activated original Windows 7 VM is still present in Working_Station_Win7.vdi, depending on when the snapshots were taken.

In addition to fth0's requests above, you might try Mpack's CloneVDI to clone the last snapshot disk in the chain then make a new VM around that clone. See the instructions for how to do this. You will need the whole chain of files though.

And though it is closing the barn door after the horse has escaped, you really need a backup routine.

The settings file doesn't have section "MediaRegistry" (is attached).

The Working_Station_Win7 does really contain MediaRegistry. It was the original VM, which was used as a base of the Cloned Win10 VM. As such it is noch so valued for me, like a Win10 one.

In the VMs-Folder of my Win10 (cloned from Win7 VM) I've found following files:
Working_Station_Win10.vbox (attached as .vbox.xml)
- It has only two snapshots - 3fa and 913 - exactly the files that are still there.
Working_Station_Win10.vbox-prev (also attached)
- seems to be the previous version (before the last delete snapshot operation) - it has three snapshots - db2, 3fa and 913 - looks like db2 was the last snapshot I've deleted.
Working_Station_Win10-1.14-linux.vbox
- looks like a backup before upgrading VirtualBox - doesn't have any snapshot information in it.

Win7 file and output of VBoxManage list hdds as a file.

The output of vboxmanage showmediuminfo \{3fa... shows the "incorrect" chain - looks bad.

Again - the HeaderInfo, shown by the CloneVDI for 3fa was pretty encouraging - it shows Working_Station_Win7.vdi as a parent - and that is the existing one.

Trying to clone 3fa didn't succeeded - it reports, that it cannot clone differencial images: I could also try to place all the images in one directory before trying to clone one of the snapshots, if I got it right. But I'll try it a bit later.

I hope you can find something useful in the provided files. If I can provide something else - let me know.

Thanks a lot for help.

I'll have to wait for a bit to look into these, got to get some work done.

Meanwhile, as for the lost Windows 10 linked clone VM, try web-searching "still possible to upgrade Windows 7 to 10 free 2020", apparently it might still be possible.

Let me guess: You are either using a symbolic link from /home/ktk/DataStore_UserPublic to /media/DataStore/Users/Public, or those are two different file systems, or you moved it at some point in time in the past. I think this is the root cause of your problems. Which one is it?

In general, when you create a linked clone of a VM, the media registry is only kept in the original VM configuration file, which also references the base virtual hard disk image. When you later delete snapshots of the clone, the original VM configuration file is usually updated accordingly, and this went wrong in your case.

If you're lucky, the VDI files have been successfully merged, their internal references (UUIDs) are correct, and only the VM configuration file(s) have to be edited accordingly. If you tell us which VDI files are available and properly chained, we could adapt the .vbox file(s) for you ...

fth0 wrote:Let me guess: You are either using a symbolic link from /home/ktk/DataStore_UserPublic to /media/DataStore/Users/Public, or those are two different file systems, or you moved it at some point in time in the past. I think this is the root cause of your problems. Which one is it?

You are right. /media/DataStore is another drive, which I've linked (as a symbolic link) to home-directories of multiple local users.

All the vdi-Files that are still there are shown as "normal" on the first screenshot in the media manager.
If I got it correctly, I could try to modify the vbox-File for Win7 with the mediaRegistry so, that the available disks are shown as connected.

KonstantinT wrote:/media/DataStore is another drive, which I've linked (as a symbolic link) to home-directories of multiple local users.

It's getting hotter with every bit of information that you share. Do you know the Highlander Principle?

If user A runs the VirtualBox Manager or one of the available VMs, they automatically start the VBoxSVC process, which from then on "owns" all VM configuration files, until the VirtualBox Manager and all available VMs are terminated. If user B does anything VirtualBox-related in this time period, you're in for a potential disaster.

KonstantinT wrote:All the vdi-Files that are still there are shown as "normal" on the first screenshot in the media manager.
If I got it correctly, I could try to modify the vbox-File for Win7 with the mediaRegistry so, that the available disks are shown as connected.

Note that while the MediaRegistry section contains the whole tree of VDI files, the cascaded Snapshot sections must match one path of the tree (from the root node to a leaf node). Additionally, make sure that nothing VirtualBox-related is running, when you edit VM configuration files "by hand" (remember the VBoxSVC process? )

After manually editing Win7.vbox file I could start Win10 VM.

Thank you, fth0 and scottgus1, very much for assistance.

Win7 had a broken MediaRegistry and one Snapshot too much.
I've also noticed, that the last vdi from the Win10 - the differential state of hard drive after last snapshot of Win10 - was not mentioned in the Win7.vbox MediaRegistry. I've added it to the Registry analogous to that of Win7.
Win10.vbox was already completely fine.

I think it could be better to make Win10 completely independent - somehow convert the linked clone into full clone VM.

fth0 wrote: If user A runs the VirtualBox Manager or one of the available VMs, they automatically start the VBoxSVC process, which from then on "owns" all VM configuration files, until the VirtualBox Manager and all available VMs are terminated. If user B does anything VirtualBox-related in this time period, you're in for a potential disaster.

I've already had an experience, that I couldn't start VM from another user, because VirtualBox Manager was running by the first one.
But actually I would expect from the serious Software provider as Oracle / VBox team, that they have integrated some kind of locking to prevent corrupting.
Anyway, currently only one user is in the vbox group. So noone else is able to start any VM.

KonstantinT wrote:I think it could be better to make Win10 completely independent - somehow convert the linked clone into full clone VM.

In the VirtualBox Manager, you could simply clone the current Win10 VM. Depending on your Windows 10 activation state, make sure to select all three keep options.

KonstantinT wrote:But actually I would expect from the serious Software provider as Oracle / VBox team, that they have integrated some kind of locking to prevent corrupting.

Well, if your usage scenario (multi-user with symbolic links) is not described in the VirtualBox User Manual, it belongs to the "you have to know what you're doing" category, and any locking being in place may or may not be enough to support such a use case. Note that multi-user without symbolic links is supported (at least on Linux hosts).

Also note that the VirtualBox forums are user-to-user forums, and that most volunteers and moderators have nothing to do with Oracle or the VirtualBox development.