virtualbox.org

I am running a Linux host (OpenSuSE 15.1) and Windows guest (Win10 Pro). Recently, Xorg crashed on the host and froze everything. I managed to SSH into the host from a different PC and issued the following command:
vboxmanage controlvm "Windows 10 Professional" savestate
I rebooted the host through SSH and logged back in. When I launched the Windows guest back, the state wasn't saved, but rather was ungraciously powered off. On the log I found the following:

08:18:23.498579 Changing the VM state from 'RUNNING' to 'SUSPENDING'
08:18:23.655548 PDMR3Suspend: 156 921 798 ns run time
08:18:23.655581 Changing the VM state from 'SUSPENDING' to 'SUSPENDED'
08:18:23.655599 Console: Machine state changed to 'Paused'
08:18:23.656956 Console: Machine state changed to 'Saving'
08:18:23.657851 Changing the VM state from 'SUSPENDED' to 'SAVING'
<SNIP>
08:19:06.795892 SSM: Successfully saved the VM state to '/home/VirtualBox VMs/Windows 10 Professional/Snapshots/2020-06-25T19-37-30-235692000Z.sav'
08:19:06.795905 Changing the VM state from 'SAVING' to 'SUSPENDED'
08:19:06.795935 Console::powerDown(): A request to power off the VM has been issued (mMachineState=Saving, InUninit=0)
08:19:06.796034 Changing the VM state from 'SUSPENDED' to 'POWERING_OFF'

What caused the VM to be Powered Off instead of Saved, even though the log shows that it was saved successfully? There is a 3.5GB .sav file on the Snapshot directory.

This is the correct sequence of log messages. Note the mMachineState=Saving on the penultimate line. You can verify it by using

When you restarted the guest, did it boot from the beginning with the Windows startup graphic, or pop back to where it was before immediately? If it popped back, then the save-state succeeded.

All Virtualbox guests power-off, even when save-stating. Here is a save-state log for an XP guest I just ran:

00:00:50.214704 Changing the VM state from 'RUNNING' to 'SUSPENDING'
00:00:51.430153 PDMR3Suspend: 1 215 383 745 ns run time
00:00:51.430186 Changing the VM state from 'SUSPENDING' to 'SUSPENDED'
00:00:51.430202 Console: Machine state changed to 'Paused'
00:00:53.833593 GUI: Request for close-action to save VM state.
00:00:53.833633 GUI: Passing request to save VM state from machine-logic to UI session.
00:00:53.835604 Console: Machine state changed to 'Saving'
00:00:53.837149 Changing the VM state from 'SUSPENDED' to 'SAVING'
00:00:53.838291 VUSB: Detached 'HidMouse' from port 1 on RootHub#1
00:00:54.964859 E1000#0: Interrupt attempts: 42
.....(several lines of E1000 stuff)
00:00:55.206460 SSM: Footer at 0x3dddb5d (64871261), 33 directory entries.
00:00:55.206714 VUSB: Attached 'HidMouse' to port 1 on RootHub#1 (FullSpeed)
00:00:55.219565 SSM: Successfully saved the VM state to 'F:\VirtualboxGuests\XP\Snapshots\2020-06-26T12-42-43-862090600Z.sav'
00:00:55.219592 Changing the VM state from 'SAVING' to 'SUSPENDED'
00:00:55.219640 Console::powerDown(): A request to power off the VM has been issued (mMachineState=Saving, InUninit=0)
00:00:55.281167 VRDP: TCP server closed.
00:00:55.281887 Changing the VM state from 'SUSPENDED' to 'POWERING_OFF'

Like fth0 says, 'POWERING_OFF' is part of a normal save-state log. Real computers do the same. After a Windows computer is hibernated, the power turns off.

It rebooted back from scratch, as if the power had gone out; it didn't resume from where it was left as expected.

This one's a puzzle. Everything looks like it save-stated. I wonder if the Xorg crash cause the Vbox service to go unstable.

When a guest save-states, it has this added to the .vbox file in the Machine UUID line:

stateFile="Snapshots/(time-stamp file name).sav"

Do some experiments and check for this line. Then see if the guest restores correctly.