Segmentation fault while starting a VM headless from snapshot

[bb90]

Given a newly created Ubuntu VM installed with Cloud-Init And a snapshot from the VM When I restore the snapshot (VBoxManage snapshot server restorecurrent --> no problem) And start the VM (VBoxManage startvm server --type headless)

Then I get 'VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component SessionMachine, interface ISession' And there is segfault log in syslog (attached).

Ubuntu 16.04.2 LTS (Xenial Xerus)
Linux HOST 4.8.0-49-generic #52~16.04.1-Ubuntu SMP Thu Apr 20 10:55:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

There is also some path mismatch. Snapshot file is here: /home/USER/VirtualBox VMs/GROUP/server/Snapshots/{b60bca32-76e8-4815-88cd-e55516a6186a}.vdi VBox wants: /home/USER/VirtualBox VMs/GROUP/server/Snapshots/2017-05-09T09-32-52-131952000Z.sav/Snapshots/2017-05-09T09-32-52-131952000Z.sav

Please fix this issue. For now, I have to revert the VirtualBox version to older, working one.

[bb90]

Also:

VBoxManage unregistervm --delete server
0%...10%...20%...30%...40%...50%...60%...
Progress state: VBOX_E_IPRT_ERROR
VBoxManage: error: Machine delete failed
VBoxManage: error: Could not delete file '/home/USER/VirtualBox VMs/GROUP/server/Snapshots/2017-05-09T09-32-52-131952000Z.sav/Snapshots/2017-05-09T09-32-52-131952000Z.sav'(VERR_FILE_NOT_FOUND)
VBoxManage: error: Details: code VBOX_E_IPRT_ERROR (0x80bb0005), component MachineWrap, interface IMachine
VBoxManage: error: Context: "RTEXITCODE handleUnregisterVM(HandlerArg*)" at line 163 of file VBoxManageMisc.cpp

[bb90]

Work around: if the newly created VM is not moved to a VM group. Than the problem does not occur. Maybe the .sav file is not moved with the VM.

[Frank Mehnert]

Would be interesting to know which older, working version of VirtualBox you are referring to.

[Frank Mehnert]

Furthermore I would like to have a step-by-step reproduction scenario for the problem triggered with VBox 5.1.22.

[bb90]

Hi frank,
I have tried 5.0 (ubuntu xenial virtualbox package), but it also was not working.
Here is a was to reproduce it. (It "works" 100% for me.)

curl ​http://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-disk1.img -o /tmp/ubuntu.img
qemu-img convert -O vdi /tmp/ubuntu.img /tmp/ubuntu.vdi
VBoxManage internalcommands sethduuid /tmp/ubuntu.vdi
VBoxManage createvm --name tst --register
VBoxManage modifyvm tst --cpus 1 --memory 256 --boot1 disk --boot2 none --boot3 none --boot4 none --nic1 nat --cableconnected1 on --ostype Linux_64 --ioapic on --defaultfrontend headless
VBoxManage storagectl tst --name SATA --add sata --portcount 1 --hostiocache on
VBoxManage storageattach tst --storagectl SATA --port 0 --device 0 --type hdd --medium /tmp/ubuntu.vdi
VBoxManage startvm --type headless tst
sleep 20
VBoxManage controlvm tst savestate
VBoxManage snapshot tst take 'system-initial'

GUI:
Right click on tst VM -> group
snapshots -> restore to system-initial (do not create new snapshot)
start the tst VM in headless mode
It should crash, VM state should be Aborted.

VBoxManage unregistervm --delete tst
Throws error, files should be deleted manually...

My theory: after grupping the VM, the *.sav file is gone...

[Frank Mehnert]

Thanks for the reproduction scenario. Actually it's not necessary to attach a disk to the VM. An empty VM shows the same problem. You are right, the problem comes from moving the VM into a group. That operation will wrongly update the path to the state file. The VBoxHeadless crash is another problem: It shouldn't crash if the state file cannot be found, it should just normally terminate. The second problem is easy to fix, the first problem (wrong path to the state file when groups are involved) is a bit more complicated.

[Frank Mehnert]

Finally found and fixed. The fix will be part of VBox 5.1.24. The most recent 5.1.x test builds (>=115382) contain the fix as well.

[bb90]

Hi frank, Thank you very much!

[Frank Mehnert]

Fix is part of 5.1.24.