VMware ESXi and vSphere Cluster Management

Configure NX/XD Bit Exposure for VMware ESXi Virtual Machines

Learn how AMD NX and Intel XD protect guest operating systems, affect vMotion CPU compatibility, and can be hidden for an individual VMware ESXi virtual machine.

Overview

AMD NX, or No Execute, and Intel XD, or Execute Disable, are processor capabilities that allow memory pages to be marked as non-executable. The names differ by processor vendor, but the security purpose is broadly comparable.

When a guest operating system can use NX/XD, it can help prevent code from executing in memory regions intended only for data. This limits some code-execution techniques, including common buffer-overflow-style attacks. Operating-system features such as Data Execution Prevention (DEP) can use this hardware support.

ESXi normally presents NX/XD support to compatible guest operating systems. The physical host CPU provides the underlying capability, while the VM receives a selected set of CPU features through virtual CPU CPUID information. Changing the VM setting changes what that VM sees; it does not disable or remove the feature from the physical host processor.

Important Terms

NX bit: AMD's No Execute processor feature for marking memory as not executable.
XD bit: Intel's Execute Disable feature, functionally comparable to AMD NX.
DEP: Data Execution Prevention, an operating-system security mechanism that can use NX/XD hardware support.
CPUID: CPU identification data exposed to software, including processor capability flags.
CPUID mask: A per-VM configuration that controls selected CPU feature bits reported to the guest operating system.
Guest operating system: The operating system running inside the virtual machine.
vMotion: VMware live migration technology for moving a running VM between compatible hosts.
CPU compatibility: The requirement that the destination host provide the processor features expected by the migrating VM.
EVC: Enhanced vMotion Compatibility, which presents a common CPU baseline across hosts in a cluster.

How NX/XD Affects vMotion

During vMotion, the destination ESXi host must provide the CPU features that the running VM expects. Hosts can otherwise appear suitable for migration while differing in a feature such as NX/XD. That difference can cause a CPU compatibility failure.

Hiding NX/XD from a specific VM changes the guest-visible CPU feature set. The guest then stops expecting that capability, which can permit migration between hosts where NX/XD availability or presentation differs. This is a compatibility workaround for one VM, not a substitute for a consistent cluster CPU design.

Before masking the feature, confirm that the migration error specifically identifies NX/XD or a related CPU feature. Masking NX/XD will not resolve an incompatibility caused by another processor feature, virtual hardware version, device, datastore, or migration restriction.

Exposure Choices and Effects

VM CPU feature presentation	Guest-visible NX/XD capability	Potential vMotion compatibility	Security implication	Typical use case
Default or exposed	Available to a supported guest	Best when source and destination hosts provide a consistent feature set	Preserves hardware-assisted non-executable memory protection	Normal operation and security-sensitive workloads
Masked or hidden	Not reported to the guest	May permit migration where NX/XD availability differs	Removes the guest-visible capability and may reduce DEP-related protection	Documented, VM-specific compatibility exception

Security and Operational Trade-Off

Masking NX/XD removes the guest-visible execution-protection capability. The guest operating system may no longer enable protections that depend on NX/XD, and security policies or applications may behave differently. The change does not make the physical host less capable, but it prevents this VM from using the capability through its virtual CPU.

Use masking only when migration compatibility requires it and after evaluating the workload. For a security-sensitive server, moving it to hosts with a consistent CPU feature baseline is generally preferable. Consider hardware standardization or an EVC-based cluster strategy to remove the underlying incompatibility.

Record the exception, the reason for it, the affected VM, the source and destination CPU differences, and the planned review date. A temporary mask should be removed after older hosts are retired or the cluster CPU baseline is corrected.

Prerequisites and Planning

Review the complete vMotion compatibility message and verify that NX/XD is the relevant difference.
Identify the CPU features presented by both the source and destination ESXi hosts.
Confirm that you have permission to edit the virtual machine configuration. See Assign Permissions if access is managed through vCenter roles.
Determine whether the installed vSphere version permits this CPU setting to be changed while the VM is powered on. Plan a shutdown, restart, or power cycle when required.
Arrange a tested backup or rollback path for important workloads.
Schedule a maintenance window if the guest must be restarted or if application testing is needed.

Configure NX/XD Exposure in the vSphere Client

The exact labels and placement vary between vSphere client releases. The following workflow uses version-neutral names and applies to the selected VM only.

Select the affected virtual machine in the vCenter inventory.
Open the VM's Edit Settings workflow.
Open or expand Virtual Hardware.
Expand the CPU configuration.
Locate CPUID Mask, or the equivalent advanced CPU-feature interface.
Find the NX/XD-related CPU feature and set it to be hidden from the guest when the compatibility exception is required. Leave it at the default or exposed state when the guest should use the protection.
Save the configuration.
Perform the required shutdown, restart, or power-cycle operation so the changed virtual CPU presentation takes effect.

For broader virtual hardware administration, see Add Virtual Hardware to VM. For general platform background, see the VMware ESXi Online Course.

Verification Checklist

Validation item	Before change	After change	Expected result
Migration error	Capture the complete message	Review any remaining message	The NX/XD-related incompatibility is resolved or another cause is identified
VM CPU configuration	Record the current exposure state	Confirm the intended mask or default state is saved	The setting belongs to the correct VM
Guest CPU capabilities	Record the guest's reported protection features where appropriate	Check after restart or power cycle	The guest sees the expected NX/XD state
vMotion test	Validate the target host and maintenance plan	Retry or test migration	The VM migrates successfully, or the remaining restriction is clear
Workload behavior	Record application and security-policy status	Test services, logs, and security controls	The workload operates acceptably with the selected feature presentation

Reversing the Change

After all destination hosts support the required NX/XD feature consistently, return the CPUID mask to its default state or expose NX/XD again. If the client or VM hardware requires it, power off and restart the VM before the guest can observe the restored capability.

After re-exposure, verify the guest's DEP or equivalent protection, test the workload, and repeat the vMotion validation. Remove the exception from your configuration records only after the VM has been confirmed to operate and migrate correctly.

Troubleshooting

vMotion Still Reports Incompatible CPUs

Another CPU feature may differ between the source and destination hosts.
The VM may not have been restarted or power-cycled.
The mask may not have been saved or may have been applied to the wrong VM.
The restriction may be unrelated to NX/XD.

Read the full compatibility error instead of assuming a single feature is responsible.
Confirm the VM's current CPU settings.
Apply the required power-state change.
Compare host CPU features and evaluate EVC or host placement options.

Guest Behavior Changes After Masking

The guest may no longer detect hardware support used by DEP or other execution-protection features. Review guest system logs, security configuration, and application behavior during a maintenance window. Restore NX/XD exposure if the compatibility workaround creates an unacceptable security or application impact.

The CPU Setting Cannot Be Edited

The VM power state or hardware configuration may prevent live modification.
Your account may lack the required virtual machine configuration privilege.
The client version may place the control under a different CPU or advanced-settings section.

Check whether the VM must be powered off, verify permissions, and use the documentation for the installed vSphere release to locate the CPU and CPUID controls.

Remediation Options

Option	Scope	Security impact	Operational impact	When to use it
Keep NX/XD exposed and standardize hosts	Cluster or hardware platform	Preserves guest-visible protection	May require hardware replacement or host evacuation	Preferred long-term design for important workloads
Configure EVC	Cluster-wide CPU baseline	Usually preserves supported features at the selected baseline	May limit newer CPU features and requires planning	When hosts can share an appropriate EVC baseline
Mask NX/XD for one VM	Individual VM	Removes that VM's guest-visible protection	Requires documentation, validation, and possibly a restart	Temporary or narrowly scoped compatibility exception
Use host placement restrictions	Selected VMs or hosts	Does not remove guest protection	Reduces scheduling and migration flexibility	When only certain hosts can safely run the workload

Practical Examples

Mixed CPU Feature Availability

A VM must move between two otherwise compatible ESXi hosts, but one host exposes NX/XD differently. The administrator verifies the compatibility message, masks NX/XD for that VM, restarts it if required, and retests vMotion. The exception is documented and reviewed.

Security-Sensitive Workload

A server uses an operating system and applications that benefit from hardware-backed non-executable memory protection. Instead of immediately masking NX/XD, the administrator compares the security impact with alternatives such as moving the VM to a consistent CPU cluster.

Temporary Compatibility Exception

During a hardware refresh, a legacy VM receives a documented CPUID mask so it can move between old and new hosts. After the legacy hosts are retired, the administrator removes the mask, restarts the VM if necessary, and validates both guest protection and vMotion.

Exam-Relevant Notes

NX and XD are vendor-specific names for comparable non-executable memory support.
DEP is an operating-system mechanism that can use NX/XD; it is not the processor feature name itself.
CPUID masking changes the features reported to one VM, not the physical host CPU.
A destination host must satisfy CPU features expected by a migrating VM.
Hiding NX/XD can improve migration compatibility but reduces the guest-visible security feature.
EVC and consistent host CPU generations are architectural solutions; per-VM masking is an exception.