Restoring snapshots does not work for Multi-processor VMs

[hunterbr]

I encountered a serious issue in Vbox 5.1.51 (compiled from source, cloned from git 25 Jan 2017), inside a Vbox VM I have Win7x64 SP1 running, everything works fine, I do a snapshot and shut down the OS. If I restore the snapshot and start the Vbox VM, the following error occurs:

cpum#1: X86_CPUID_FEATURE_EDX_HTT is not supported by the host but has already exposed to the guest [ver=17 pass=final] (VERR_SSM_LOAD_CPUID_MISMATCH).

Result Code:
NS_ERROR_FAILURE (0x80004005)
Component:
ConsoleWrap
Interface:
IConsole {872da645-4a9b-1727-bee2-5585105b9eed}

This only happens with VMs with more than one CPU. If I discard the snapshot I can start the machine with two CPU without a problem. If I se t it to one CPU, the snapshots are working.

The Vbox app is running inside an Ubuntu 16.04.1LTS which is running inside VMware Worksation VM(details below).

VBox running inside an:

• Ubuntu 16.04.1 LTS
• Linux ubuntu 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

running inside a VM from:

• VMware® Workstation 12 Pro
• 12.5.2 build-4638234

• Memory 4GB
• Processors: 4 (num cores 1)
• Virtualization Engine:
• Prefered mode: Automatic
• Disable acceleration for binary translation: not set
• Virtualize Intel VT-x/EPT or AMD-V/RVI: enabled
• Virtualize CPU performance counter: enabled
• HD: 200GB

[Frank Mehnert]

So you are actually talking about VirtualBox running inside VMware, correct? I would like to see a VBox.log file of the VM which you tried to restore.

[hunterbr]

Update: There is an easy workaround: If I change the VMware Workstation setting to 2 processors with 2 cores each, instead of 4 processors with 1 core, the hyperthreating bit is set by VMware (cat /proc/cpuinfo on Ubuntu includes ht) and the restored snapshop of the Vbox is starting properly.

So this issue will probably never happen on a real physical CPU, only with my double virtualization setup (see below) and a virtual CPU with one core it happens. Nevertheless, there seems to be something wrong with the CPUid checks in VBOX after restoring the snapshot as far as the HT bit was never set on this virt. CPU before either and the Guest OS worked, it only fails to restore snapshots.

Setup: PC(Vmware(Ubuntu(Vbox(Win7)))

[hunterbr]

error log

[hunterbr]

workaround log

[hunterbr]

here are the logs, one with the workaround (2cpu 2 cores) and one where the error occurs (4 cpu 1 core).

HTH, Holger

[Frank Mehnert]

Thanks. I would also like to see the VBox.log file of the VM session when the VM state was saved. I have the suspicion that the VMware configuration changed between saving the VBox VM state (taking the snapshot) and restoring the state.

[hunterbr]

Replying to frank:

Thanks. I would also like to see the VBox.log file of the VM session when the VM state was saved. I have the suspicion that the VMware configuration changed between saving the VBox VM state (taking the snapshot) and restoring the state.

sorry, I don't have that anymore, but the issue is rebuild'able. If it is very important for you I will rebuild it, but you can trust me the VM config (neither VMware nor Vbox) was not changed (at least not manually by me - maybe from vbox itself). Between taking the snapshot and testing it were only a few minutes and no one else had access to this setup.

[Frank Mehnert]

Ok, nevermind. I think you found a bug which is not triggered on real hardware because the HTT bit (CPUID(eax=1), EDX.28) is almost always set on recent CPUs. The workaround for you is indeed to enable hyperthreading in your VMware VM settings.

[Frank Mehnert]

Fix in r65459.

[Frank Mehnert]

Fix is part of VBox 5.1.16.