VirtualBox

Ticket #6460 (closed defect: wontfix)

Opened 4 years ago

Last modified 3 months ago

Can't start a previously saved VM after replacing CPU, even when the new one is perfectly compatible

Reported by: durval Owned by:
Priority: major Component: GUI
Version: VirtualBox 3.0.12 Keywords: CPU change, saved VM restart
Cc: Guest type: Windows
Host type: Linux

Description (last modified by frank) (diff)

The problem:

After replacing my computer's motherboard and CPU (because the old ones died), I can't start any previously saved VMs; even discarding the current state doesn't help if the last snapshot was made with the machine running; seems discarding the full snapshot would be needed to be able to start this VM again.

More details:

Previous motherboard, CPU: Aopen i975AX-YDG, Intel Merom T5600 Replacement motherboard, CPU: Intel S3210SHLC, Intel Yorkfield Q9550 O/S: Ubuntu Hardy 8.04 LTS, all updates applied. VBox: 3.0.12 r54655 PUEL, downloaded directly from  http://www.virtualbox.org/wiki/Downloads

Possible solutions:

1) Quick workaround: just tell me where I can poke on the .sav file with a binary editor so I can change VBox' idea of the old CPU to be exactly equal to the new one and so try to bypass the trouble, or else how can I restart this VM by booting it (as the snapshot was made with the machine running, it seems I have no way to simply reboot it from the snapshotted disk, or at least I can't find it in the GUI).

2) "Definitive" solution: make the "CPU checking" logic smarter so that when moving to a newer CPU that's a "proper superset" of the old one (i.e, has everything the old one has), it won't refuse to run the saved state from the old one.

3) Perhaps an even better (and easier to implement) solution: when VBox detects that the CPU has changed, instead of refusing to run the saved state just prompt the user with a dialog box where he/she is warned that the CPU has changed, and that it's possible that the saved machine won't run properly; then, offer the user the option to continue at hos/her own risk, or to abort the run.

For other cases and background, please see this VBox forum topic:  http://forums.virtualbox.org/viewtopic.php?f=6&t=28750, specially my 2 posts at  http://forums.virtualbox.org/viewtopic.php?f=6&t=28750#p131230 and  http://forums.virtualbox.org/viewtopic.php?f=6&t=28750#p131233

Attachments

VBox.log Download (61.1 KB) - added by durval 4 years ago.
VBox log file produced when trying to start the VM after replacing the CPU

Change History

Changed 4 years ago by durval

VBox log file produced when trying to start the VM after replacing the CPU

comment:1 Changed 3 years ago by sergiomacedo

Is there any workaround yet for this problem?

It's easy to have a scenario where you simply can't discard the last running snapshot after an upgrade for a compatible CPU.

Isn't there any "extradata/DontBlameVirtualBox" that can be enabled to totally ignore this check or at least loosen it a bit more?

Thanks for any update on this issue!

comment:2 Changed 3 years ago by sergiomacedo

BTW I don't think the problem is GUI related... it's way down to the core engine...

comment:3 Changed 3 months ago by frank

  • Status changed from new to closed
  • Resolution set to wontfix
  • Description modified (diff)

CpuId mismatch. In principle VBox ignores certain CPUID features but I assume that in this case the difference was too big. See here.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use