a performance counter used by the guest is not available on the host cpu

[dotis]

Windows 8

VMWare Workstation 9

After performing a Windows update this morning I can't resume my suspended session.

"A performance counter used by the guest is not available on the host CPU."  With the option to "preserve" which does not restore and "discard" which I am afraid will cause me to lose data.

My questions are can I work around this?  Edit the .vmss file in some way to remove the counter?  Identify and add the missing counter to my host?  Can I discard without losing data?

[dotis]

This looks like the relevant log entry:

2013-02-12T12:06:36.775-07:00| vmx| I120: guestCpuFeatures = 0x402001fd

2013-02-12T12:06:36.777-07:00| vmx| I120: DUMPER: Item 'csRights' [0, -1] not found.

2013-02-12T12:06:36.777-07:00| vmx| I120: Msg_Question:

2013-02-12T12:06:36.777-07:00| vmx| I120: [msg.vpmc.unavailcounters] A performance counter used by the guest is not available on the host CPU.

2013-02-12T12:06:36.777-07:00| vmx| I120: [msg.checkpoint.restore.cpufail] An error occurred while restoring the CPU state from file "F:\Delphi XE 2011\Windows 7 Dev-2a3600b8.vmss".

2013-02-12T12:06:36.777-07:00| vmx| I120: [msg.checkpoint.resume.softError] Your virtual machine did not resume because of a correctable error. Preserve the suspended state and correct the error, or discard the suspended state.

2013-02-12T12:06:36.777-07:00| vmx| I120: ----------------------------------------

2013-02-12T12:16:39.273-07:00| vmx| I120: MsgQuestion: msg.checkpoint.resume.softError reply=0

2013-02-12T12:16:39.273-07:00| vmx| I120: Module CheckpointLate power on failed.

[611]

Sorry for necroposting, but this topic is the first link Google gives for the error message text.

It looks like host power status history matters:

This morning I've got in the same situation - VM failed to resume with this error.

I'm running VMs on my laptop (i7 version of X230T), and in most cases VMs are started after several suspend-wake cycles of the host, not when the host is freshly booted from power-off state.

But after installation of Windows updates the host is freshly booted, so I've tried to reproduce the starting conditions - sent my laptop to suspend mode, woke it up, and tried to resume the VM again.

And it worked - VM resumed without errors!

Hope this will help someone

[willowmaster]

I have seen this error now and then, but couldn't make it work. Finally someone who knows the solution! Thanks!

[lucienmp]

2018, and this hasnt been a problem until very recently.

I refuse to believe I always started my VM on my laptop after a suspend.

The above solution works, to recap:

1. If you started the VM after a freshboot, then you must always resume the VM from a freshboot

2. If you started the VM after a suspend, then you must always resume the VM from a resume

3. You can shutdown and reboot the VM, then after a suspend of the VM it will need the same power state on the laptop.

Host OS: Windows 10 1803

Guest OS:  CentOS7

VMWare: 14.1.2

TBH; this is extremely annoying, is there any other way to fix this?

[lol36]

This is 2020, and it still exists.

Host: Ubuntu 20.04 focal

Guest: Windows 10 2004

VMware: 15.5.6

[Scissor]

If this happens after monthly Windows Update patches (or linux patches) are installed on your Host then my first theory is that the patches included updated CPU microcode.  Intel and AMD periodically release CPU microcode updates and operating system vendors include them in their patches.  Microcode updates are applied at every boot.  Updated microcode can change what CPU features are exposed to the operating system, which *may* explain the behavior you see.

Another theory I have is that the BIOS of your Host does something different initializing the CPU when resuming vs restarting.  Check for a BIOS update for your Host.  For example, this user noticed that their CPU no longer exposed VT-x when the system was resumed from suspend.  No news on if a BIOS update fixed it though:   https://community.intel.com/t5/Processors/vt-x-is-disabled-after-i5-4460-resume-from-sleep-mode/td-p...

Or, sorry to say this, shut down your Guest VMs before you suspend/shutdown your Host.  (if your Guests are running Windows 10 then you should consider disabling Fast Startup so they truly shut down -- see: https://www.windowscentral.com/how-disable-windows-10-fast-startup .  Also turn off the "sleep after x minutes" option.)  This is what I have trained myself to do. 

On a side note, are you suspending your Guests because they take much longer than expected to shut down (especially if they have been sitting idle for hours)?  Turning off Memory Page Trimming (under VM > Settings > Options > Advanced > check "Disable memory page trimming") fixed that for me.

Hope this helps.

[Woodler]

After I read the last post I was able to identify the issue. Some VMs booted correctly and some did not. I found the difference was on VM settings > processors>"Virtualize CPU performance counters". So my new best practice is to uncheck this until I really need it in VM. 

[JFITServices]

🤣Dude, this is gorgeous! And applies to (Fedora 39) Linux the same way, too. Who would have thought...

I suffered from this a thousand times by now but yesterday I got carefree, and suspended a VM with tons of unsaved data. Shut down the host after that for the night. And of course, today VMware wouldn't start because two kernel modules needed to be recompiled after a kernel update yesterday. Uh-oh. As VMware consistently fails to recompile them automatically, it's a routine script by now but still a pain in the a**.

After that, VMware Workstation would readily start VMs but refused to restore my suspended one due to the dreaded performance counter difference. Looked in the logs and found nothing useful about it. I so wish that VMware would offer to start the VM at my own risk, or at least share some detail about what is the actual difference, but that's another story. As this time it was crucial that the VM wakes up from suspension, no matter what, so I invested some more time.

So eventually I found this thread, no idea why not sooner. What do you know, suspending (which never actually worked on my machine anyway) for a short period of time and bringing the system back up would fix the issue! 😜

Which in turn apparently means that the data about the suspended VM includes not only the current processor's power state but past states as well? What good is that? Is a host system resumed from suspension different in any way from the same host freshly booted, regarding its virtualization capabilities?

But anyway, thank you so much for sharing this. I couldn't be happier now, and I owe you a beer or two!