VM config lost after saving state

[commorancy0]

I've had this issue happen several times recently. I click to save the state of a VM. It saves the state completely and the window closes. I then close out of VirtualBox (UI).

The next time I open the Vbox UI, the VM looks normal. However, when I attempt to start the VM, I'm greeted with "Fatal: no boot media". It seems that the *.vbox file may have been saved incorrectly as a result of the previous shutdown. What I see in the UI is that the entire Storage area is blank (it's lost all of the hard drives, CD, etc). It also has reset the memory and possibly other settings. It's almost like it's overwritten the *.vbox file with a generic template. Or, perhaps a generic template is created because the original *.vbox file has gone missing... not sure which?

I have encountered this bug at least 3 times since 5.1.18. I am still seeing it in the latest version (5.1.22). So, whatever is causing this issue is not fixed. Two of the times, I could easily recreate the VMs. However in this latest one, I need to recover some information for reference.

As an FYI, the *.vdi hard drive files exist. In the snapshot director, I see the *.sav file and the various snapshot files. Unfortunately, trying to hand recreate the working *.vbox file for this VM the way that it was is probably next to impossible.

Note that this VM began its life as a linked clone from another VM. I have not modified the original from which it was cloned, so it shouldn't be related to that. However, for each of these I have encountered, they have all been from linked clones making recreating the *.vbox file more complicated.

It would be great if there were a repair tool included to scan the VM's directory and attempt to repair or recreate the *.vbox file using the files it can find. If such a tool already exists, please let me know. If there's an easy way to recreate this *.vbox file, that would be helpful.

As an FYI, I've also looked at the 'backup' *.vbox file and it also appears to be a generic template. So, I can't even recover from that.

[Carlos D.]

Now that sounds very familiar... I suspect this is at least related to my #15373 ticket.

Looks like the process that parses the contents of *.vbox files at GUI startup also attempts to sanitize them. Unfortunately, when it encounters certain odd situations, there seems to be a problem that wipes out *.vbox contents.

In my case, some VMs that are controlled through the API (BOINC science tasks), managed to attach a DVD Image (the VBOX Guest additions ISO) with a conflicting UUID. Those API-controlled tasks are never shut down, but always put into saved state (like yours). The settings of those tasks are wiped out, together with all other VMs that have the same DVD Image attached.

You might have a similar problem. The sanitizing process should correct errors or conflicting settings in the *.vbox files (e. g. one hard disk or ISO that exists with multiple conflicting UUIDs). But it either deletes too much or corrupts the XML structure (which is then recreated empty).

1. VM memory is set to 128MB.
2. Display memory is set to 8MB, display settings are lost.
3. Network is wiped.
4. Storage settings are empty.
5. Sound is disabled.
6. USB settings gone.
7. Shared folders wiped.
8. The saved state and all snapshot settings are lost.

Sounds familiar? The worst is that the backup settings file is also overwritten.

Check the "Screenshot Test2 after bug strike" image attached to my ticket (mentioned above), yours certainly looks the same way.

[commorancy0]

Hi Carlos,

Thanks for your comment. Your image does look similar. These two bugs could very well be related. It may be as you suggest, that the bug rears its head during some kind of parser sanity check. Whatever the bug, it's like playing Russian Roulette with your VMs never knowing when any individual VM might be wiped. This is a fairly severe bug.

I've had to start keeping separate backups of all of my *.vbox files "just in case". I can't afford to have any of my critical VMs just up and disappear. Some of them I've spent hours configuring and I don't relish the thought of having to redo that work a second time.

[Carlos D.]

Isn't that just great? This ticket is downright ignored, exactly as mine.

I really thought danger of losing VM metadata and settings (not to mention SNAPSHOTS) would get some priority. Guess not...

[Frank Mehnert]

Replying to Carlos D.:

Isn't that just great? This ticket is downright ignored, exactly as mine.

I really thought danger of losing VM metadata and settings (not to mention SNAPSHOTS) would get some priority. Guess not...

Please provide a reliable scenario and we will try to fix. So far we were never able to reproduce the problem.

[Carlos D.]

Well, let's try it from a different angle.

Scenario: There are two or more VMs in your VBox collection that have conflicting Media Registry entries (in my case, same DVDImage ISO, but different UUID). Don't ask me how that can happen, but it does. The GUI should prevent that, however, some VMs like BOINC tasks are controlled through API from the outside and might bypass GUI checks.

Now my question: What actually is supposed to happen when you start the VBox GUI and multiple VMs have conflicting Media Registry entries?

1. (Only) the conflicting entries are removed or sanitized?
2. Such VMs show an error one must correct manually?

What actually happens is (the good, the bad, and the ugly):

• The conflicting Media Registry entries are removed (good).
• Everything inside the XML file following the Media Registry entries is also removed (VERY BAD). Entries above the Media Registry stay untouched.
• If you do not notice the problem right away, the only backup of the *.vbox file is eventually also overwritten (the ugly).

Recreating the immediate problem when there are conflicting DVDImage entries is easy.

1. Start a completely fresh VBox instance from scratch.
2. Register two VMs with completely stock settings. They must both have a hard disk registered or it won't work.
3. Register the same ISO in both VMs (I used the VBoxGuestAdditions.iso).
4. Exit the GUI, wait until the service quits.
5. For the sake of re-creating the underlying problem (which happens sporadically, unfortunately), edit the VBox file of the second VM to have a different UUID for the registered ISO (at both locations inside the XML). Changing one character suffices. Save the file.
6. Start the GUI again and check the settings of the VMs. One of them will be broken.

Note that without having any hard disks registered, the second VM simply shows an error ("Cannot register the DVD image 'C:\Program Files\Oracle\VirtualBox\VBoxGuestAdditions.iso' {dad73ea7-25e8-4d71-ad4d-6c62343b64d1} because a CD/DVD image 'C:\Program Files\Oracle\VirtualBox\VBoxGuestAdditions.iso' with UUID {ead73ea7-25e8-4d71-ad4d-6c62343b64d1} already exists.") which I assume is the correct behavior?