VMware ESXi and vSphere Cluster Management

Use the VMware CPU Identification Utility to Assess vMotion CPU Compatibility

Learn how to obtain, boot, and interpret the VMware CPU Identification Utility to compare CPU features and assess vMotion compatibility across ESXi hosts.

Before moving a running virtual machine with vMotion, the destination ESXi host must be able to execute the virtual machine with CPU capabilities compatible with those available on the source host. The VMware CPU Identification Utility helps you inspect the processor characteristics and feature flags visible to a host.

This utility is a diagnostic aid, not an automatic vMotion certification tool. Use its report together with vCenter validation, the configured Enhanced vMotion Compatibility (EVC) policy, the vSphere release, virtual machine settings, and current VMware interoperability guidance.

Why CPU Compatibility Matters for vMotion

vMotion moves the execution state of a running virtual machine between hosts. During migration, the destination must provide a compatible CPU execution environment. If the destination lacks a CPU capability that the virtual machine or source host depends on, migration may be blocked or the virtual machine may not run correctly after the move.

A processor family or model name is only a summary. Two servers that appear to use similar CPUs can expose different capabilities because of processor stepping, firmware configuration, microcode, hypervisor policy, or virtualization settings. Conversely, different processor generations may be made compatible for many workloads through feature masking and EVC.

Vendor specification sheets describe the processor's potential capabilities, but they do not necessarily show every feature available at runtime. BIOS or UEFI settings, platform firmware, the ESXi version, and an outer hypervisor in a nested lab can change which features are visible to the hypervisor.

What the VMware CPU Identification Utility Does

The VMware CPU Identification Utility is a VMware-provided diagnostic tool that reports processor identification data and CPU features visible to the system. The download is typically a ZIP archive containing bootable media, including an ISO file named cpuid.iso.

CPUID refers to the processor identification information and feature flags exposed through the CPU instruction interface. The report can show items such as the processor vendor, family, model, stepping, instruction-set capabilities, and security-related capabilities.

• It reports what the diagnostic environment can observe.
• It does not change ESXi, CPU settings, or cluster configuration.
• It does not automatically certify that a vMotion operation is supported.
• It does not replace vCenter compatibility checks or VMware support documentation.

Workflow for Using the Utility

Phase — Action — Expected Result — Operational Consideration

Obtain — Download the utility from the appropriate VMware or Broadcom software or support location — A ZIP archive is available — Authenticated access may be required.

Prepare — Extract the archive and locate cpuid.iso — The bootable ISO is ready — Verify the download and use a release appropriate for the environment where possible.

Attach — Write the ISO to optical media or map it as virtual optical media — The target host can boot the utility — Confirm that the media mapping is intact.

Boot — Select the optical device with a one-time boot menu — The diagnostic environment starts independently of installed ESXi — Schedule a maintenance window for physical hosts.

Record — Capture CPU identity and feature fields — A comparable report exists for the host — Record results for every possible vMotion participant.

Evaluate — Compare reports with EVC, VM requirements, and vSphere guidance — Potential compatibility risks are identified — Similar reports alone do not prove migration support.

Validate — Check vCenter and test representative migrations — The planned configuration is tested — Use change control and workloads that reflect production.

Obtain and Prepare cpuid.iso

1. Sign in to the applicable VMware or Broadcom software download or support location. Access may require an authenticated account or an entitlement.
2. Download the CPU Identification Utility ZIP archive using a trusted administrative workstation.
3. Verify the downloaded file using any checksum or signature information supplied with the download. At minimum, confirm that the file completed successfully and was obtained from the intended software channel.
4. Extract the ZIP archive without modifying the ISO contents.
5. Confirm that cpuid.iso exists and that its size and extracted files are consistent with the release information.
6. Record the utility version and the host, firmware, and ESXi versions being tested. A release suited to the environment is preferable when multiple versions are available.

The ISO can be used in two ways:

• Physical media: write the ISO to bootable optical media using an ISO-aware media-writing tool. Copying the ISO as an ordinary file is not the same as writing an image.
• Virtual media: use a server management controller's virtual CD/DVD feature, or attach the ISO to a virtual machine CD/DVD device.

Boot a Physical ESXi Host

1. Evacuate or shut down workloads according to the maintenance plan. Confirm that the host can be safely restarted.
2. Insert the optical media, or use the server's remote-management controller to map cpuid.iso as virtual CD/DVD media.
3. Restart the server.
4. Open the firmware boot menu or remote-management boot controls. The exact key and menu differ by server manufacturer.
5. Select the local optical drive or remotely mapped virtual CD/DVD device. Prefer a one-time boot selection instead of permanently changing the boot order.
6. Allow the diagnostic environment to start and follow its on-screen instructions.

The utility runs independently of the ESXi installation on the server's disk. When finished, remove or disconnect the ISO and select the normal ESXi boot device during the next restart.

Run the Utility in a Nested ESXi Lab

Nested ESXi is an ESXi instance operating as a virtual machine on another virtualization platform. It is useful for learning and testing, but its CPU report describes the virtual CPU presented by the outer hypervisor.

1. Power off the nested ESXi virtual machine, or use the lab's supported procedure for changing its boot media.
2. Open the virtual machine hardware settings and attach cpuid.iso to its virtual CD/DVD device.
3. Set the device to connect at power-on.
4. Set the CD/DVD device as the next boot target, either with a one-time virtual boot menu or by temporarily changing the virtual machine boot sequence.
5. Start the virtual machine and inspect the report.
6. Disconnect the ISO or restore the normal boot order when testing is complete.

A nested report reflects the features exposed by the outer hypervisor and the virtual machine's CPU configuration. It may omit capabilities present on the physical processor. Nested-virtualization settings, virtual CPU compatibility settings, and feature masking can further restrict what the guest ESXi instance sees. For production migration planning, compare reports collected directly from the physical ESXi hosts.

Read and Record the CPU Feature Report

Begin by recording the processor identity:

• Vendor: the CPU manufacturer reported by CPUID.
• Family and model: processor identification values used to distinguish CPU generations and designs.
• Stepping: a revision identifier that can matter when otherwise similar processors differ.
• Instruction-set capabilities: flags for processor instructions and execution features.
• Security-related capabilities: features such as no-execute memory protection and other processor security functions.

Collect the same fields for every host that may be a source or destination for vMotion. Store the host name, hardware model, exact CPU identity, BIOS or UEFI version, ESXi version, utility version, and report date with each result.

Report Item — Why It Matters — Example Difference — Recommended Follow-up

Vendor, family, model — Establishes the broad processor identity — One host reports a newer family or model — Check supported combinations and the intended EVC baseline.

Stepping — Can indicate a processor revision — Matching model names have different stepping values — Compare exact identifiers and firmware versions.

Instruction flags — May be required by a virtual machine or exposed by the source host — A flag appears on one host but not another — Check EVC, VM CPU requirements, and vCenter compatibility messages.

Security flags — Affect protection features and sometimes host or VM requirements — NX/XD is absent on one report — Review BIOS/UEFI settings and repeat the test after an approved change.

Visible versus expected features — Shows what the hypervisor can actually use — The specification sheet lists a feature that the report lacks — Investigate firmware, microcode, hypervisor, or nesting effects.

When comparing reports, highlight features present on one host but absent or hidden on another. Do not treat every difference as an automatic failure. Interpret each difference in the context of the vSphere version, the virtual machine's CPU configuration, the cluster EVC policy, and the guest workload's requirements.

NX and XD: No-Execute Memory Protection

The NX bit and XD bit are processor names for a no-execute capability. NX means No Execute; XD means Execute Disable, Intel's terminology for the same general type of memory-protection feature. It allows designated memory pages to be marked non-executable, helping prevent code from running in data-only memory regions.

Capability — Common Vendor Name — Typical Firmware Label — Effect When Unavailable

No-execute protection — NX bit — NX, No Execute, or Execute Protection — The report may omit the capability and security-dependent software or platform requirements may not be satisfied.

Execute-disable protection — XD bit — XD, Execute Disable, or Execute Disable Bit — The CPU feature is not exposed to the hypervisor until the firmware setting and platform support are corrected.

If the report does not show the expected NX or XD capability:

1. Confirm that the report was collected from the intended physical host rather than a nested guest.
2. Enter the server BIOS or UEFI configuration during an approved maintenance period.
3. Look for settings named NX, XD, Execute Disable, No Execute, Execute Protection, or a similar security option.
4. Review related processor virtualization and security settings that can affect hypervisor-visible features.
5. Document the original setting and assess platform and workload implications before changing it.
6. Enable the setting only when supported by the hardware documentation and organizational policy.
7. Perform the required controlled reboot, rerun the utility, and confirm that the capability is now reported.

Firmware changes require a reboot and may affect other platform behavior. Do not change them casually on an active production host.

Use Findings for vMotion Planning

Use the reports to identify hosts with matching or sufficiently compatible CPU capabilities. Possible actions include:

• Group hosts with compatible processors into the same migration or cluster boundary.
• Align BIOS or UEFI settings and firmware levels where appropriate.
• Use EVC as the normal cluster-level method for presenting a common CPU baseline.
• Keep incompatible hardware in separate clusters or migration groups.
• Retest representative virtual machines after changing firmware, EVC, or host membership.

EVC, or Enhanced vMotion Compatibility, masks selected newer CPU features so virtual machines see a common baseline supported by the participating hosts. This is called feature masking. EVC can simplify migration across some CPU generations, but it cannot make unsupported CPU generations compatible in every scenario. It also cannot create a hardware feature that is absent when the virtual machine or platform requires it.

After reviewing the reports, check the cluster's EVC mode and confirm that its baseline is appropriate for every participating host. Then use vCenter's migration compatibility checks and test representative workloads. A successful diagnostic comparison is evidence for investigation, not a substitute for the complete vSphere validation process.

Practical Example: Compare Two Candidate vMotion Hosts

1. Schedule an approved maintenance period for both physical hosts.
2. Evacuate workloads and boot each host with cpuid.iso.
3. Capture the vendor, family, model, stepping, instruction flags, security flags, utility version, and firmware details.
4. Place the two reports side by side and highlight feature flags that are present on one host but absent on the other.
5. Compare the differences with the cluster's current or intended EVC baseline and with the CPU requirements of representative virtual machines.
6. Decide whether to align firmware, enable an appropriate EVC mode, separate the hosts, or use hardware with a common CPU generation.
7. After configuration changes, validate migration in vCenter and test representative workloads before using the path for routine production operations.

This process identifies a likely CPU-compatibility risk before a production vMotion attempt. It does not eliminate other prerequisites such as vMotion networking, licensing, datastore access, host state, and cluster configuration.

Practical Example: Test the Utility with Nested ESXi

1. Power off the nested ESXi virtual machine.
2. Attach cpuid.iso to its virtual CD/DVD device and connect the device at power-on.
3. Set the virtual optical device as the one-time boot target.
4. Start the VM and record the reported processor and feature fields.
5. Compare the nested result with a report collected directly from the physical host.
6. Explain any differences using the outer hypervisor's CPU compatibility mode, virtual CPU settings, and nested-virtualization configuration.

The lab result teaches how virtual hardware affects feature exposure. It should not be used as the sole basis for production host compatibility decisions.

Practical Example: Resolve a Missing NX or XD Feature

1. Confirm in the report that the expected no-execute capability is absent.
2. Check whether the test was performed on bare metal and whether the processor supports the capability.
3. Review BIOS or UEFI for NX, XD, Execute Disable, or equivalent labels.
4. Compare the setting with a working host and consult platform documentation.
5. Enable the setting if policy and hardware support permit it, using change control and a scheduled reboot.
6. Run the utility again and record the updated report.
7. Use vCenter and VMware guidance to determine whether the change resolves the actual migration or workload requirement.

Troubleshooting

The Host Ignores the ISO

• Verify that the ISO was written as an image rather than copied as a normal file.
• Confirm that remote virtual media is mapped and connected.
• Use the firmware boot menu or a one-time boot override to select the optical device.
• Check whether Secure Boot, boot mode, or firmware policy prevents the selected media from starting.
• Disconnect the ISO after testing so the server returns to the installed ESXi boot device.

The Nested ESXi VM Does Not Boot the Utility

• Confirm that the ISO is attached to the correct virtual CD/DVD device.
• Set the device to connect at power-on.
• Use the VM boot menu or a temporary boot-order change.
• Confirm that the virtualization platform can access the ISO path or datastore.

Similar Servers Show Different Reports

• Compare BIOS or UEFI versions and processor-related settings.
• Compare microcode and ESXi versions where applicable.
• Check exact CPU family, model, and stepping values instead of relying on product names.
• Confirm that both reports were collected under equivalent conditions and that neither came from nested ESXi.
• Assess the difference against EVC compatibility and current VMware support guidance.

vMotion Is Still Unavailable

• Check whether EVC is disabled or configured with an unsuitable baseline.
• Review the virtual machine's CPU configuration and feature requirements.
• Check vCenter migration messages, vMotion VMkernel networking, licensing, host state, and cluster prerequisites.
• Confirm that the host and CPU combination is supported for the relevant vSphere release.

Operational Cautions and Limitations

• Booting the ISO disrupts a physical host. Evacuate workloads and use maintenance mode and change control as appropriate.
• BIOS or UEFI settings can expose or hide CPU capabilities.
• Microcode and hypervisor versions can alter the features visible at runtime.
• Nested virtualization settings can limit the CPU features visible to nested ESXi.
• A specification sheet and a utility report describe different things: potential hardware capability versus observed runtime exposure.
• The utility is a diagnostic aid. Current VMware interoperability guidance and vCenter validation remain authoritative for supported configurations.

Exam-Relevant Notes

• vMotion compatibility depends on executable CPU capabilities, not only the processor's marketing family or model name.
• cpuid.iso is the bootable ISO included with the utility's ZIP download.
• NX and XD describe no-execute memory protection; firmware can hide or expose it.
• Nested ESXi reports the CPU presented by the outer hypervisor, not necessarily the complete physical CPU.
• EVC provides a common CPU baseline through feature masking, but it cannot solve every cross-generation or missing-feature problem.
• Similar CPU reports do not replace vCenter checks for the full set of vMotion prerequisites.

Summary

The VMware CPU Identification Utility provides a practical way to inspect processor identity and feature flags visible to an ESXi environment. Download and extract the utility, boot physical hosts during approved maintenance windows, or attach cpuid.iso to a nested ESXi VM for lab testing. Record the same fields for every possible migration participant, investigate feature differences such as NX/XD, and interpret the findings with EVC, VM requirements, vSphere versions, firmware, and VMware support guidance. For additional study, see VMware CPU Identification Utility.