VMs no longer start from saved state

[LennyHers]

Since I've upgraded to 5.2.10r122088 (Ubuntu 16 LTS, Kernel: 4.4.0-121-generic), I'm no longer able to start my VMs from saved state:

Waiting for VM "VM_W10" to power on...
VBoxManage: error: The VM session was aborted
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component SessionMachine, interface ISession

The vbox log (attached) doesn't say much. This happens on all ~150 vms across all 10 vbox hosts I have.

[LennyHers]

core dump: ​https://we.tl/jC40MGbxzo

[Socratis]

Are you restoring from 5.1.26?

00:00:18.885124 SSM: File header: Format 2.0, VirtualBox Version 5.1.26 r117224, 64-bit host, cbGCPhys=8, cbGCPtr=8

and are you running headless all of them?

00:00:00.030042 Executable: /usr/lib/virtualbox/VBoxHeadless

Typically, a saved state should be error free if restored from a VirtualBox of the same major version, with only a few minor versions in between, not across major versions, you might have issues, like in your case...

But, I'm not the one making the call whether it's a bug or not, I'm only suggesting to avoid that tactic in the future; always shut down your VMs before a major VirtualBox upgrade.

[Socratis]

Can you please try the latest test build from wiki:Testbuilds ?

There was a fix regarding saved-states restoration. Can you check if it works in your case?

[LennyHers]

Replying to socratis:

Are you restoring from 5.1.26?

No, I've upgraded from vbox 5.2.x. However, the saved-states have been created with a previous version of vbox (quite some time ago, not sure which version that was).

00:00:18.885124 SSM: File header: Format 2.0, VirtualBox Version 5.1.26 r117224, 64-bit host, cbGCPhys=8, cbGCPtr=8

and are you running headless all of them?

Yessir.

00:00:00.030042 Executable: /usr/lib/virtualbox/VBoxHeadless

Typically, a saved state should be error free if restored from a VirtualBox of the same major version, with only a few minor versions in between, not across major versions, you might have issues, like in your case...

But, I'm not the one making the call whether it's a bug or not, I'm only suggesting to avoid that tactic in the future; always shut down your VMs before a major VirtualBox upgrade.

I'm running ~150 VMs. Shutting them all down and create a new saved state for each of them is a no-go for me.

[LennyHers]

Replying to socratis:

Can you please try the latest test build from wiki:Testbuilds ?

Done.

There was a fix regarding saved-states restoration. Can you check if it works in your case?

Problem (bug?) fixed. Thank you!

Do you know when the test build will make it into the master / productive build?

[Socratis]

Replying to LennyHers:

quite some time ago, not sure which version that was

It's right there in the text that I quoted: 5.1.26, I was just looking for confirmation...

00:00:18.885124 SSM: File header: Format 2.0, VirtualBox Version 5.1.26 r117224, 64-bit host, cbGCPhys=8, cbGCPtr=8

I'm running ~150 VMs. Shutting them all down and create a new saved state for each of them is a no-go for me.

In cases like that, your no-go might have to turn to a yes-go if there was no alternative. A pain? Yes, a royal one. The alternative being an actual "no-go"? I think that you'd "yes-go". Never say never... ;)

Problem (bug?) fixed. Thank you''

I'm sure that some fallen angel just got their wings back! :D

Do you know when the test build will make it into the master / productive build?

No, but you got to think of the test builds as "intermediate" builds, in between releases. They're not your alpha/beta builds with untested/unproven code. I could even go so far as to call them production-ready. So, keep on using the test builds, until an official release comes out.

No clue when that's going to happen. "They" don't talk about release dates (which is a "good thing"™). But, since I keep a record, here are the days in between 5.2.x releases, starting with 5.2.0: 36, 27, 27, 27, 42, 49 days. Do the math... :D