Looking at the top of the stack trace it shows dtrace_psinfo_alloc so I am guessing the crash is related to the dtrace module.
Do you know if dtrace enabled in an OEL VM requires virtual performance counters (VPMC) to be enabled on the VM CPU settings? I don't think version 12.5.x would be able to initialise the VPMC properly for host with Kaby Lake/Coffee Lake CPUs. Did you have to disable the VPMC in order to power up the OEL VM on the i7-8700 host?
VPMC is one of those features where the hypervisor will need to do some extra stuff before it can be available in the VM.
If you look at the vmware.log (look for the text codename), you will likely find the codename is probably Pentium 3 or Pentium (unknown)
| vmx| I125: hostCPUID codename:
While the codename in itself is not important, it does indicate that Workstation Pro hypervisor won't be able to initialise the correct microarchitecture for VPMC inside a VM.
If you don't use dtrace within the VM, you could try removing dtrace (using the i7-4702MQ host) from the OEL VM and see whether that allows you to power up the OEL VM on the i7-8700 host.
Thanks for the help.
Dtrace is not installed in the system.
About the codename is:
guest vs. host CPUID guest codename: Pentium Core -- Unknown codename
I attach the VMWare logfile , of the last run, in case you see something that can help.
vmware.log.zip 22.8 K
From the looks of it, a part of DTrace is built-in to the kernel. https://oss.oracle.com/projects/DTrace/
It is composed of three portions, an in-kernel core, a userspace utility, and a type storage library used by these.
The kernel portion is built into the UEK kernels and is also available on a public git tree.
So your VM might not have the DTrace tools but it could still be in the kernel. You could try the steps to outlined here to remove the DTrace kernel bits although it is for a different issue.
for package in `rpm -qa | grep dtrace-modules`; do yum remove -y $package; done
On a Crystal Well (Haswell) Macbook Pro with Fusion 8.5.10, the vmware.log shows the following vpmc capabilities even though the virtualised performance counters is not enabled in the Windows 10 VM.
| vmx| I125: Capability Found: vpmc.numGenCtrs = 0x4
| vmx| I125: Capability Found: vpmc.fixedWidth = 0x30
| vmx| I125: Capability Found: vpmc.genWidth = 0x30
| vmx| I125: Capability Found: vpmc.version = 0x3
| vmx| I125: Capability Found: vpmc.microarchitecture.haswell = 0x1
| vmx| I125: Capability Found: vpmc.genctr.0 = 0x1
| vmx| I125: Capability Found: vpmc.numFixedCtrs = 0x3
I would think you would find similar entries in the vmware.log of the OEL VM on the i7-4702MQ host. For now, I am thinking that the DTrace kernel bits, given its functionality/purpose, might be assuming performance counters from the virtual CPU to be present but are not there and therefore the OEL VM is crashing on the boot-up.
The rest seem to be OK (for example, the TSX-NI capabilities are found)
vmx| I125: Capability Found: cpuid.RTM = 0x1
vmx| I125: Capability Found: cpuid.HLE = 0x1
Other things you could do although I don't think it will make any difference on the Coffee Lake host making the OEL VM successfully power up.
Update Workstation Pro to 12.5.9 (it is a free update), 12.1.0-build-3272444 you use is quite old and does not have the necessary security fixes (including exposing the Spectre microcode to VMs).
Upgrade the OEL VM hardware compatibility from version 11 to 12 (from VM menu - Manage)
You are great!
Now after remove the dtrace packages, the system boot fine.
Many Thanks, for you help!
Hi Arturo, I'm having the same issue, how did you uninstall the dtrace packages? it doesn't seem to be installed either in my server.