- $ VBoxManage.exe controlvm <uuid> savestate
leaves the VM in an aborted state. In Logs/VBox.log I see the following:
- $ grep "VM state" VBox.log
00:00:00.972364 Changing the VM state from 'CREATING' to 'CREATED'.
00:00:00.977306 Changing the VM state from 'CREATED' to 'POWERING_ON'.
00:00:00.998114 Changing the VM state from 'POWERING_ON' to 'RUNNING'.
00:02:28.626006 Changing the VM state from 'RUNNING' to 'SUSPENDING'.
00:02:28.722622 Changing the VM state from 'SUSPENDING' to 'SUSPENDED'.
00:02:28.728527 Changing the VM state from 'SUSPENDED' to 'SAVING'.
00:02:30.033601 SSM: Successfully saved the VM state to 'C:\Users\xxxxx\VirtualBox VMs\trusty64_default_1410996474733_91815\Snapshots\2014-09-17T23-30-27-735
155700Z.sav'
00:02:30.033612 Changing the VM state from 'SAVING' to 'SUSPENDED'.
00:02:30.033687 Changing the VM state from 'SUSPENDED' to 'POWERING_OFF'.
00:02:30.033801 Changing the VM state from 'POWERING_OFF' to 'OFF'.
00:02:30.034611 Changing the VM state from 'OFF' to 'DESTROYING'.
00:02:30.040039 Changing the VM state from 'DESTROYING' to 'TERMINATED'.
If I then show the vm state
- $ VBoxManage.exe showvminfo <uuid>| grep State
State: saved (since 2014-09-17T23:30:29.069000000)
I see state is saved, but this invocation of VBoxManage.exe crashes. If I immediately run it again
- $ VBoxManage.exe showvminfo <uuid>| grep State
State: aborted (since 2014-09-17T23:33:05.833000000)
The state is now "aborted". That isn't the expected behavior, is it?