merging of snapshots destroys VM

[Eduard Warkentin]

Whenever I try to merge a snapshot, regardless of wether I get error messages about OBJECT NOT FOUND or wether the merge is successful, I am unable to (re)start the VM, since a snapshot file is missing.

Trying to restart Virtualbox GUI ends up in a warning that there are missing disk files, the missing snapshot.

This happens on Linux hosts, OSX hosts, with Virtualbox 5.0.0 to 5.0.8.

For me, its totally breaking virtualbox, and I am forced to downgrade to 4.3.32.

Please just add a comment in case you need more information.

[Frank Mehnert]

From your description it sounds like snapshots is completely broken with VBox 5.0.x but works with VBox 4.3.32. Did you already try a minimal test setup with VBox 5.0.x? For example, create a dummy VM with a new hard disk attached, then create a snapshot and merge it. Is the problem reproducible with this minimal setup as well (here it isn't)?

[Eduard Warkentin]

I was able to reproduce the problem as followed, using VirtualBox 5.0.8:

• created minimal test VM, the configuration is attached to this ticket
• started VM and stopped VM
• created snapshots snap1, snap2, snap3
• started VM and stopped VM
• deleted snapshot snap3, snap2, snap1
• started VM and stopped VM
• created snapshots snap1, snap2, snap3
• started VM
• deleted snapshot snap2
• created snapshots snap4, snap5, snap6
• deleting snapshot snap1 results in the following error message:

  NS_ERROR_FAILURE (0x80004005)
  

I suspect this is due to the change mentioned in the changelog:

API: block the removal of the current snapshot if it has child snapshots (only relevant for VMs without snapshottable hard disks, their presence always prevented removal), which resulted in VM config corruption

• deleted snap3
• deleting snapshot snap6 results in the following error message:

  VERR_ACCESS_DENIED.
  Fehlercode: NS_ERROR_FAILURE (0x80004005)
  Komponente: ConsoleWrap
  Interface: IConsole {872da645-4a9b-1727-bee2-5585105b9eed}
  

At this time, I could observe I/O errors inside the VM, and I had to power it off

• Closing and restarting the VirtualBox GUI resulted in the following error message upon trying to start the VM again:

  Für die virtuelle Maschine testvm konnte keine neue Sitzung eröffnet werden.
  Locking of attached media failed.
  A possible reason is that one of the media is attached to a running VM.
  Fehlercode: VBOX_E_INVALID_OBJECT_STATE (0x80BB0007)
  Komponente: SessionMachine
  Interface: IMachine {f30138d4-e5ea-4b3a-8858-a059de4c93fd}
  

The output of:

   VBoxManage list hdds

shows the following:

UUID:           2ee90a3d-0db9-43d2-a8fe-d12daff56c2b
Parent UUID:    base
State:          created
Type:           normal (base)
Location:       /Users/camel/VirtualBox VMs/Ubuntu Farm/testvm/testvm.vmdk
Storage format: VMDK
Capacity:       10240 MBytes
Encryption:     disabled

UUID:           d44e7c82-be4e-48da-b006-9f0aae46d959
Parent UUID:    2ee90a3d-0db9-43d2-a8fe-d12daff56c2b
State:          created
Type:           normal (differencing)
Location:       /Users/camel/VirtualBox VMs/Ubuntu Farm/testvm/Snapshots/{d44e7c82-be4e-48da-b006-9f0aae46d959}.vmdk
Storage format: VMDK
Capacity:       10240 MBytes
Encryption:     disabled

UUID:           9cb1d9b4-23fa-4d16-92ba-3ae355f75baa
Parent UUID:    d44e7c82-be4e-48da-b006-9f0aae46d959
State:          created
Type:           normal (differencing)
Location:       /Users/camel/VirtualBox VMs/Ubuntu Farm/testvm/Snapshots/{9cb1d9b4-23fa-4d16-92ba-3ae355f75baa}.vmdk
Storage format: VMDK
Capacity:       10240 MBytes
Encryption:     disabled

UUID:           c00e9808-68ab-464c-9e43-4222f5f5ac1b
Parent UUID:    9cb1d9b4-23fa-4d16-92ba-3ae355f75baa
State:          inaccessible
Type:           normal (differencing)
Location:       /Users/camel/VirtualBox VMs/Ubuntu Farm/testvm/Snapshots/{c00e9808-68ab-464c-9e43-4222f5f5ac1b}.vmdk
Storage format: VMDK
Capacity:       0 MBytes
Encryption:     disabled

UUID:           54731db7-e8bb-41ac-b307-bdca671094f5
Parent UUID:    c00e9808-68ab-464c-9e43-4222f5f5ac1b
State:          created
Type:           normal (differencing)
Location:       /Users/camel/VirtualBox VMs/Ubuntu Farm/testvm/Snapshots/{54731db7-e8bb-41ac-b307-bdca671094f5}.vmdk
Storage format: VMDK
Capacity:       10240 MBytes
Encryption:     disabled

As can be seen, for UUID c00e9808-68ab-464c-9e43-4222f5f5ac1b, the file is inaccessible.

• Restored snapshot snap5
• Deleting snapshot snap4 results in the following error message:

  VBOX_E_FILE_ERROR (0x80BB0004)
  

• Closing and restarting the VirtualBox GUI did not help at this point, eliminating the possibility that this is just a GUI issue

The output of:

   VBoxManage list hdds

now shows the following:

UUID:           2ee90a3d-0db9-43d2-a8fe-d12daff56c2b
Parent UUID:    base
State:          created
Type:           normal (base)
Location:       /Users/camel/VirtualBox VMs/Ubuntu Farm/testvm/testvm.vmdk
Storage format: VMDK
Capacity:       10240 MBytes
Encryption:     disabled

UUID:           d44e7c82-be4e-48da-b006-9f0aae46d959
Parent UUID:    2ee90a3d-0db9-43d2-a8fe-d12daff56c2b
State:          created
Type:           normal (differencing)
Location:       /Users/camel/VirtualBox VMs/Ubuntu Farm/testvm/Snapshots/{d44e7c82-be4e-48da-b006-9f0aae46d959}.vmdk
Storage format: VMDK
Capacity:       10240 MBytes
Encryption:     disabled

UUID:           9cb1d9b4-23fa-4d16-92ba-3ae355f75baa
Parent UUID:    d44e7c82-be4e-48da-b006-9f0aae46d959
State:          inaccessible
Type:           normal (differencing)
Location:       /Users/camel/VirtualBox VMs/Ubuntu Farm/testvm/Snapshots/{9cb1d9b4-23fa-4d16-92ba-3ae355f75baa}.vmdk
Storage format: VMDK
Capacity:       0 MBytes
Encryption:     disabled

UUID:           c00e9808-68ab-464c-9e43-4222f5f5ac1b
Parent UUID:    9cb1d9b4-23fa-4d16-92ba-3ae355f75baa
State:          inaccessible
Type:           normal (differencing)
Location:       /Users/camel/VirtualBox VMs/Ubuntu Farm/testvm/Snapshots/{c00e9808-68ab-464c-9e43-4222f5f5ac1b}.vmdk
Storage format: VMDK
Capacity:       0 MBytes
Encryption:     disabled

UUID:           54731db7-e8bb-41ac-b307-bdca671094f5
Parent UUID:    c00e9808-68ab-464c-9e43-4222f5f5ac1b
State:          created
Type:           normal (differencing)
Location:       /Users/camel/VirtualBox VMs/Ubuntu Farm/testvm/Snapshots/{54731db7-e8bb-41ac-b307-bdca671094f5}.vmdk
Storage format: VMDK
Capacity:       10240 MBytes
Encryption:     disabled

UUID:           a5b8403b-6888-46a5-a3eb-4d1a6142bb76
Parent UUID:    9cb1d9b4-23fa-4d16-92ba-3ae355f75baa
State:          created
Type:           normal (differencing)
Location:       /Users/camel/VirtualBox VMs/Ubuntu Farm/testvm/Snapshots/{a5b8403b-6888-46a5-a3eb-4d1a6142bb76}.vmdk
Storage format: VMDK
Capacity:       10240 MBytes
Encryption:     disabled

As can be seen for UUID c00e9808-68ab-464c-9e43-4222f5f5ac1b and UUID 9cb1d9b4-23fa-4d16-92ba-3ae355f75baa now, both files are inaccessible.

The following files do exist for the VM:

Ubuntu Farm/testvm//Logs/VBox.log
Ubuntu Farm/testvm//Logs/VBox.log.1
Ubuntu Farm/testvm//Logs/VBox.log.2
Ubuntu Farm/testvm//Logs/VBox.log.3
Ubuntu Farm/testvm//Snapshots/2015-11-02T23-22-58-724111000Z.sav
Ubuntu Farm/testvm//Snapshots/2015-11-02T23-24-39-764932000Z.sav
Ubuntu Farm/testvm//Snapshots/{54731db7-e8bb-41ac-b307-bdca671094f5}.vmdk
Ubuntu Farm/testvm//Snapshots/{a5b8403b-6888-46a5-a3eb-4d1a6142bb76}.vmdk
Ubuntu Farm/testvm//Snapshots/{d44e7c82-be4e-48da-b006-9f0aae46d959}.vmdk
Ubuntu Farm/testvm//testvm-s001.vmdk
Ubuntu Farm/testvm//testvm-s002.vmdk
Ubuntu Farm/testvm//testvm-s003.vmdk
Ubuntu Farm/testvm//testvm-s004.vmdk
Ubuntu Farm/testvm//testvm-s005.vmdk
Ubuntu Farm/testvm//testvm-s006.vmdk
Ubuntu Farm/testvm//testvm.vbox
Ubuntu Farm/testvm//testvm.vbox-prev

I've attached the relevant log files as well.

[avarner]

I'll add that it also happens reliably on Windows.

Virtual machines that are corrupted in this way cause VirtualBox to periodically crash (at intervals of around 5 minutes), so the destroyed virtual machine needs to be deleted to continue safely.