This is largely a guess, so take this all with a pinch of salt.
I encountered something that may be related where, when vmware was configured to 'grab' and 'release' the keyboard/mouse when the cursor moved in and out of the vmware window. I switched using a specific keypress to grab and release. Basically, in the preferences under keyboard/input control I unchecked most of the options. (I recall switching from the default control+alt to something else, because I suspected a window manager key binding was conflicting somehow.)
At the very, absolute worst, figure out how to add a global startup item that on your centos machine's that executes a script containing:
{ while sleep 2; do xset r on; done } &
Good luck!
P.S. When I had the similar problem, before I figured how to fix it, I would just ssh into my guest linux VMs or rdesktop into my guest windows VMs. In the end, I found that approach to be much nicer. Certainly made it gobs easier to move files back and forth using ssh ControlSockets or the rdesktop -r disk: redirection. Just a thought.
[Edit: Potentially worthwhile details I discovered.]
While poking around trying to find evidence proving GTK at fault, I used strings on the binaries to find a poorly documented configuration statement to increase MKS (mouse keyboard screen) logging. Then I discovered the following strings:
MKS Keyboard: Reset auto-repeat = %d
MKS Keyboard: Restore on-grab auto-repeat = %d
MKS Keyboard: Restore power-on auto-repeat = %d
MKS Keyboard: Auto-repeat = %d
MKS Keyboard: Saved power-on global_auto_repeat = %d
MKS Keyboard: On-grab global_auto_repeat = %d
MKS Keyboard: Saved on-grab global_auto_repeat = %d
Clearly, formatting for conditional log messages. Unfortunately, I've been unable to reproduce your problem so I can't test this myself, but near those log messages I found another string, I suspect a configuration file label. Try adding this to your ~/.vmware/preferences and your VM's .vmx file
mks.x.saveAutoRepeatEveryGrab = "TRUE"
I don't know what that statement causes and it may be the default condition - the very opposite may be necessary. These might enable the logging that would pin the problem down. I don't know if they belong in the VMX or in the preferences, so I would add them to both.
mks.x.printXError = "TRUE"
mks.dbg = "TRUE"
mks.mksDbg = "TRUE"
If you do discover what was causing this, please do let me know.
Good Luck.
If you are running VM tools, the tool has an option to periodically sync the time with the host.
If in your path:
vmware-toolbox-cmd timesync status to view and
vmware-toolbox-cmd timesync disable to stop it.
Of course any non-vm method of time sync could be there as well. If the system starts ntpd, it may be syncing that way. You could run ntpd -q to see if the system responds with associations. If so, it will probably sync with them. You'd then want to disable ntpd.
Best Answer
The
lscpu, if installed, synthesize somehow the information given bycat /proc/cpuinfo. In particular you can take a look at the fieldsCPU(s),Core(s) per socketandSocket(s).