Opened 9 years ago
Last modified 9 years ago
#14679 new defect
Deleting Snapshot Error: VBOX_E_FILE_ERROR (0x80BB0004) - File not accessible or erroneous file contents
| Reported by: | NightDragon | Owned by: | |
|---|---|---|---|
| Component: | other | Version: | VirtualBox 5.0.4 |
| Keywords: | delete snapshot VBOX_E_FILE_ERROR (0x80BB0004) | Cc: | |
| Guest type: | other | Host type: | other |
Description
Build used "5.0.4.102546" on Gentoo Linux 64 bit (binary package, so i did not need to compile anything), Modules Version "5.0.4". Guest: "Windows 10 Pro 64Bit"
When deleting a snapshot it seems it comes to some sort of race condition inside virtualbox. Afterwards the VM can't be used anymore, without setting it back to a snapshot before the deleted one. It's randomly reproducible. There are no errors known on the storage (harddisk, raid, and filesystem are clean and checked without errors). This issue can reproduced on running VM's (deleting a live snapshot) or on pwoered off VMs.
Running the command from above results in a deleted snapshot file. Reverting to an older snapshot in the dependency tree works fine and the VM is runnable. Reverting to a newer snapshot is not possible (as the depending parent snapshot of course is missing). The vbox file was not updated by the command.
VBoxManage snapshot "Gaming01" delete aa95f360-73a3-4b9a-958b-d21845d2f08a 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%... Progress state: VBOX_E_FILE_ERROR VBoxManage: error: Snapshot operation failed VBoxManage: error: Code VBOX_E_FILE_ERROR (0x80BB0004) - File not accessible or erroneous file contents (extended info not available) VBoxManage: error: Context: "RTEXITCODE handleSnapshot(HandlerArg*)" at line 527 of file VBoxManageSnapshot.cpp
Attachments (1)
Change History (2)
by , 9 years ago
| Attachment: | Gaming01.zip added |
|---|
comment:1 by , 9 years ago
Build used "5.0.4.102546" on Gentoo Linux 64 bit (binary package, so i did not need to compile anything), Modules Version "5.0.4". Guest: "Windows 10 Pro 64Bit"
When deleting a snapshot it seems it comes to some sort of race condition inside virtualbox. It's randomly reproducible. There are no errors known on the storage (harddisk, raid, and filesystem are clean and checked without errors). This issue can reproduced on running VM's (deleting a live snapshot) or on pwoered off VMs.
Running the command from below results in a deleted snapshot file. Reverting to an older snapshot in the dependency tree works fine and the VM is runnable. Reverting to a newer snapshot is (of course) not possible (as the depending parent snapshot is missing - the one deleted with VBoxManage). The Command doesn't update the vbox file - seems it's a step after deleting the file.
The command was executed with the VDI found in line 15 of the vbox-file: "<HardDisk uuid="{f3fd2d39-2e66-4800-8352-da460b3797fd}" location="Snapshots/{f3fd2d39-2e66-4800-8352-da460b3797fd}.vdi" format="VDI">"
And later again with the VDI found in line 4: "<HardDisk uuid="{2d5b0d8f-6124-4fea-9f57-b77f1c8c088e}" location="Snapshots/{2d5b0d8f-6124-4fea-9f57-b77f1c8c088e}.vdi" format="VDI">"
Error Message:
VBoxManage snapshot "Gaming01" delete aa95f360-73a3-4b9a-958b-d21845d2f08a 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%... VBoxManage: error: Snapshot operation failed VBoxManage: error: Code VBOX_E_FILE_ERROR (0x80BB0004) - File not accessible or erroneous file contents (extended info not available) VBoxManage: error: Context: "RTEXITCODE handleSnapshot(HandlerArg*)" at line 527 of file VBoxManageSnapshot.cpp
I tried it with two different branches in the tree.
List of VDI-Files:
shadowghost Snapshots # ls -l -h --color=no
insgesamt 189G
-rw------- 1 root root 1,7G 24. Sep 20:06 2015-09-24T18-05-52-725253000Z.sav
-rw------- 1 root root 1,3G 28. Sep 22:40 2015-09-28T20-40-18-492739000Z.sav
-rw------- 1 root root 9,3G 29. Sep 01:16 2015-09-28T23-12-29-455297000Z.sav
-rw------- 1 root root 1,5G 2. Okt 22:27 2015-10-02T20-26-48-375667000Z.sav
-rw------- 1 root root 1,6G 3. Okt 00:48 2015-10-02T22-48-15-931339000Z.sav
-rw------- 1 root root 24G 3. Okt 15:58 2015-10-03T13-48-18-565581000Z.sav
-rw------- 1 root root 1,4G 3. Okt 15:59 2015-10-03T13-58-39-577705000Z.sav
-rw------- 1 root root 662M 6. Okt 01:00 2015-10-05T23-00-40-661956000Z.sav
-rw------- 1 root root 2,1G 7. Okt 00:09 2015-10-06T22-09-02-849665000Z.sav
-rw------- 1 root root 18G 2. Okt 22:50 {43568adc-bb4a-4a9e-b73f-42a26af1f533}.vdi
-rw------- 1 root root 20G 7. Okt 00:09 {4411231c-ffc2-4221-8b90-1229ef288744}.vdi
-rw------- 1 root root 2,0M 6. Okt 21:03 {45912de7-8ef5-4154-85d0-91c27a9bb4b4}.vdi
-rw------- 1 root root 14G 6. Okt 21:18 {4cbc1227-6b6c-40c4-8fc1-e9e1fc5a2b4e}.vdi
-rw------- 1 root root 12G 7. Okt 11:46 {560de620-7a26-44b5-b21a-7a1495b0b222}.vdi
-rw------- 1 root root 22G 2. Okt 22:27 {61fed515-b8e9-48cf-8b41-4976a4889f20}.vdi
-rw------- 1 root root 144M 3. Okt 15:59 {6acfd8e4-bd2d-40e9-b608-baaed36191eb}.vdi
-rw------- 1 root root 17G 6. Okt 01:00 {a2912be3-0ed0-400e-976d-9659dd416d68}.vdi
-rw------- 1 root root 22G 3. Okt 15:58 {cfb2ff72-45b5-4310-9baf-9e27d9e51ea0}.vdi
-rw------- 1 root root 8,4G 6. Okt 21:01 {df390d65-2f44-4b2a-86dc-48c7f2e11354}.vdi
-rw------- 1 root root 3,7G 3. Okt 00:48 {eaa4b715-0ac6-42f1-ad62-b5162f4208f9}.vdi
-rw------- 1 root root 13G 2. Okt 22:50 {fb9d8b23-47af-4d81-8ef6-0c1f0ae95f5e}.vdi
vbox-File