VMware exposes NUMA configuration to a VM with the help of virtual NUMA, the virtual topology configuration is stored in the VM’s vmx file. By default, the vNUMA configuration for a VM is created only once – when a VM was first time powered on. During the VM lifecycle the vNUMA will be changed only when a CPU resource or vNUMA advanced options are modified, vMotion is NOT affecting vNUMA (by using default settings). If the on-premises physical servers configuration differs from one used in VMware Cloud on AWS, it’s expected that after migration the vNUMA configuration of your VM may not be aligned with the new hardware. This might introduce performance penalties for application workload especially visible on a VM with more than 8 vCPUs (nine is the lower limit for the vNUMA exposure).
To check vNUMA configuration of your VM we recommend using a PowerShell script, providing a framework to execute a “grep” against vmware.log file of a VM without directly connecting to an ESXi host and presenting all relevant vNUMA information about the VM in question.
NOTE: The script is read-only, no changes to the VM configuration will be made.
If the vNUMA configuration does not match the one on your new physical server in VMware Cloud on AWS, you should reconfigure vNUMA by using either VM advanced settings (by changing numa.autosize.once = "FALSE”) or by temporarily changing the number of vCPUs assigned.
For you reference, the server models used in VMware Cloud on AWS have the following NUMA configuration:
As a rule of thumb, for a VM having less than 18/24 cores and 256/384 GB RAM on i3/i3en instances respectively, only a single vNUMA node should be exposed.
NOTE: Make yourself familiar with the NUMA concept and VMware implementation of vNUMA. The vNUMA blog series by Frank Denneman is highly recommended. Also check out the VMworld session: “60 Minutes of Non-Uniform Memory Architecture (HBI2278BE)”*
* VMworld account required