VMware ESXi and vSphere Cluster Management

Use the VMware CPU Identification Utility to Assess vMotion CPU Compatibility

Learn how to boot the VMware CPU Identification Utility, compare CPU feature flags, check NX/XD settings, and evaluate vMotion and EVC compatibility.

Live migration with vMotion moves a running virtual machine from one ESXi host to another. The destination host must be able to provide a CPU execution environment compatible with the source host and the virtual machine. Processor model names are useful inventory labels, but the CPU feature flags exposed through CPUID are often more important for migration compatibility.

The VMware CPU Identification Utility is a bootable VMware diagnostic that reports processor characteristics and feature flags. This lesson shows how to obtain and boot the utility, record its results, investigate differences such as NX/XD, and use the findings as one part of a broader vMotion and Enhanced vMotion Compatibility (EVC) assessment.

Why CPU feature identification matters in vSphere

A CPU feature flag is a bit that indicates a processor capability. Examples include instruction-set extensions, virtualization-related capabilities, and security features. The processor instruction CPUID returns identification data and feature bits that software can inspect.

During vMotion, the virtual machine may continue using CPU instructions that were available on the source host. The destination must support the relevant instruction set and expose a compatible view to the virtual machine. A mismatch can prevent migration or cause a compatibility warning.

Two servers can both be advertised as using a similar processor family while differing in:

• CPU generation, family, model, or stepping
• Instruction-set extensions
• Security capabilities such as no-execute support
• Firmware settings that hide or expose processor features
• Hypervisor policies that mask features from guests

Consequently, compare the actual reported capabilities rather than relying only on a product name, clock speed, socket count, or vendor description. For related planning, see CPU compatibility for vMotion.

What the VMware CPU Identification Utility does

The utility is a VMware-provided, bootable diagnostic environment. It starts independently of the installed ESXi image and inspects the processor view presented by the platform. Its report commonly includes the CPU vendor, family, model, stepping, and supported instruction or security features.

The download is distributed as an ISO image inside an archive. An ISO image is a file containing the contents and boot information of optical-disc media. Extract the archive before attempting to attach the ISO; attaching the compressed archive itself will not normally produce bootable media.

Use the report for comparison and compatibility assessment. Do not treat it as a method for changing ESXi CPU settings. EVC, firmware configuration, VM configuration, and cluster design are managed through their respective supported interfaces.

Obtain and prepare the boot media

1. Use the applicable VMware or Broadcom software/download portal and authenticate if an entitlement or account is required.
2. Download the utility archive appropriate to the platform and vSphere generation being assessed.
3. Extract the archive on an administration workstation.
4. Locate the bootable CPU utility ISO and retain the original archive and extraction details for audit purposes.
5. Choose a media method: physical optical media, a server's out-of-band management virtual-media function, or a virtual machine CD/DVD device.

Out-of-band management provides server access independently of the host operating system. A server remote console can usually attach an ISO as virtual media and present it as a bootable optical device.

In a virtual lab, attach the ISO to an ESXi virtual machine running under a supported desktop or nested virtualization product. This creates a nested ESXi scenario: an ESXi instance operates as a virtual machine inside another hypervisor. The report then describes the CPU features exposed by the outer hypervisor, not necessarily every capability of the physical processor.

Boot-media configuration checklist
1. Extract the archive.
2. Identify the bootable ISO.
3. Attach it to physical, remote, or virtual CD/DVD media.
4. Select the attached media in a one-time boot menu or firmware boot order.
5. Confirm that the utility, rather than normal ESXi, starts.

Prepare the ESXi host and boot the utility

Rebooting a production ESXi host interrupts host availability unless its workloads are safely evacuated. Before starting, review the maintenance procedure, migrate suitable virtual machines to other hosts, power off workloads that cannot be moved, and place the host in maintenance mode when appropriate. See maintenance mode for the operational concept.

For a physical host, insert the disc or connect virtual media, restart, and select the optical or virtual-media device. For a nested lab, attach the ISO to the VM's virtual CD/DVD device, enable connection at power-on if required, select the virtual device as the boot device, and restart the VM.

Read and record the CPU feature report

Record every candidate vMotion host using the same method and format. Capture a complete report when possible, not only the CPU name. Keep the report with the host's hardware inventory, BIOS/UEFI version, firmware settings, ESXi version, and date of collection.

For each feature, classify the result as present, absent, or different. A difference is not automatically a migration blocker, but it is a reason to check vCenter compatibility diagnostics, EVC support, firmware settings, and the affected virtual machine's requirements.

Example comparison workflow

1. Boot host A and capture vendor, family, model, stepping, and feature flags.
2. Boot host B using the same utility and capture the same fields.
3. Place the reports side by side or normalize them in an inventory worksheet.
4. Highlight features present on one host but absent on the other.
5. Check whether the difference relates to a supported EVC baseline, a firmware setting, or a genuine hardware limitation.
6. After all non-CPU prerequisites are satisfied, perform a controlled vMotion test with a suitable virtual machine.

NX, XD, and Execute Disable support

The NX bit is AMD terminology for a processor capability that marks memory pages as non-executable. Intel uses XD, or Execute Disable Bit, for an analogous capability. Firmware menus may use labels such as NX, No-Execute Memory Protection, Execute Disable Bit, or XD.

Firmware can hide or expose this capability to ESXi and guests. If the report does not show an expected NX/XD capability:

1. Compare the report with the processor and server documentation.
2. Inspect BIOS/UEFI security and processor settings.
3. Record the original setting and confirm that a change is supported by the server vendor and organizational policy.
4. Enable the supported setting if approved.
5. Reboot and run the utility again to confirm that the capability is exposed.

Relationship to vMotion and EVC

CPU inspection is one input to vMotion planning. A successful migration also depends on vCenter and cluster requirements, vMotion VMkernel networking, storage accessibility or supported storage migration, licensing, VM hardware and device configuration, and the state of both hosts. Review Enhanced vMotion concepts and the relevant vMotion checks separately.

Enhanced vMotion Compatibility (EVC) is a cluster-level capability that presents a common, supported CPU feature baseline to virtual machines. By hiding newer features from VMs, EVC can make hosts with supported CPU-generation differences appear more alike for migration purposes.

See EVC explained and EVC requirements before selecting a baseline. A CPU mismatch may require avoiding cross-host migration, placing hosts in separate clusters, or using a compatible host group rather than forcing an unsupported configuration.

Document results and make a decision

Use a repeatable evidence-based process:

1. Inventory each host's manufacturer, model, CPU family/model/stepping, BIOS/UEFI version, ESXi version, and firmware settings.
2. Collect a utility report from every candidate host during approved maintenance windows.
3. Compare feature presence, absence, and meaningful differences.
4. Verify unexpected results against processor documentation and firmware settings.
5. Determine whether a supported EVC baseline covers the older or least capable host.
6. Validate cluster, VM, networking, storage, licensing, and vMotion prerequisites independently.
7. Test a controlled migration and retain the result with the inventory.

If no supported common CPU baseline exists, do not place the hosts in the same migration domain merely because their commercial model names look similar. Use a compatible host group, separate cluster design, restricted placement, or a hardware refresh according to the operational requirement.

Troubleshooting

The system starts ESXi instead of the utility

• Verify that the ISO was extracted and attached correctly.
• Check the optical or virtual-media device in the one-time boot menu.
• Confirm that the media is connected at power-on for a virtual machine.
• Check whether the ISO is intact and retry with a newly extracted copy.

The report differs from physical CPU specifications

• Check BIOS/UEFI settings and firmware revision.
• In a nested environment, inspect the outer hypervisor's CPU exposure or masking configuration.
• Repeat the test on physical hardware when the goal is physical-host compatibility.

vMotion remains unavailable even though reports look similar

• Review detailed feature comparisons and EVC support.
• Use vCenter migration compatibility diagnostics.
• Validate vMotion networking, storage, VM devices, licensing, and cluster configuration separately.

NX/XD is absent

• Confirm that the processor and platform support the capability.
• Review the firmware setting and its vendor-specific name.
• Check whether nested virtualization or CPU masking prevents exposure.
• After an approved firmware change, reboot and rerun the report.

The utility is unavailable in the portal

Standalone utility availability and support can vary by vSphere release and software-portal policy. Authenticated entitlement may be required, or the tool may no longer be distributed for a particular platform generation. Consult current VMware/Broadcom product documentation and use supported vCenter compatibility checks and EVC planning guidance when the utility cannot be obtained.

Operational cautions and exam notes

• Rebooting an ESXi host without evacuating or shutting down workloads can interrupt service.
• A CPU feature flag describes a capability exposed by the current platform configuration; it is not always a complete description of the physical processor.
• NX and XD are vendor-specific names for broadly analogous no-execute functionality.
• EVC supplies a common feature baseline; it does not repair unsupported vendors, missing hardware, firmware problems, or non-CPU vMotion failures.
• The CPU Identification Utility supports assessment and comparison. It does not itself configure EVC or guarantee migration success.
• For exams and production planning, distinguish CPU compatibility from vMotion network, shared-storage, VM-configuration, licensing, and cluster prerequisites.

For a broader foundation, review the VMware ESXi online course, then apply the findings alongside your documented cluster design and migration requirements.