VMware ESXi and vSphere Cluster Management
Hide or Expose the NX/XD Bit for VMware ESXi vMotion Compatibility
Learn what AMD NX and Intel XD do, how CPUID masking controls their visibility in VMware vSphere, and when hiding or exposing the feature affects vMotion compatibility.
AMD NX (No Execute) and Intel XD (Execute Disable) are equivalent processor security capabilities. In VMware vSphere, the feature can be exposed to or hidden from a virtual machine through its CPU configuration. This setting can matter when vMotion moves a running VM between ESXi hosts with different CPU capabilities.
What the NX/XD Bit Does
The NX bit is AMD's No Execute feature. Intel provides the equivalent feature under the name XD bit, or Execute Disable. Both names describe the same general security function: marking selected memory regions as non-executable.
Non-executable memory is memory marked so that processor instructions cannot be executed from it. An operating system can place data, such as buffers, in these regions while allowing programs to execute only from designated code areas.
This separation helps reduce the impact of some code-execution attacks. For example, a buffer-overflow-style exploit may attempt to place malicious instructions in a data buffer and then execute those instructions. NX/XD does not eliminate every vulnerability, but it can prevent execution from memory pages that the operating system has marked as data.
In a virtual machine, NX/XD is a CPU capability presented to the guest operating system. The guest can detect the capability and use it when its kernel, memory manager, and applications support no-execute protections.
| CPU vendor | Feature name | Meaning | Guest-visible purpose |
|---|---|---|---|
| AMD | NX bit | No Execute | Allows the guest to mark selected memory pages as non-executable. |
| Intel | XD bit | Execute Disable | Provides the equivalent general-purpose memory-execution protection. |
Default Virtual Machine Behavior
Supported guest operating systems normally receive the NX/XD capability by default when the virtual machine and its eligible ESXi hosts can provide it. Exposing the capability allows a supported guest OS to enable the associated memory-execution protections.
The default presentation does not mean that the VM adds NX/XD hardware to an ESXi host. The physical processors already provide, or do not provide, the capability. vSphere controls which supported CPU feature bits the guest is allowed to see.
Why NX/XD Can Affect vMotion
vMotion is the live migration of a running virtual machine between ESXi hosts. For the migration to work reliably, the source and destination hosts must provide sufficient CPU compatibility. The VM must be able to run with a consistent virtual CPU feature set before and after the move.
An NX/XD mismatch is one possible compatibility difference. For example, one host may expose execute-disable support while another host does not provide the same capability. The hosts may otherwise have compatible processors, but the difference can still appear in the vMotion compatibility check.
A CPUID instruction is a processor identification and feature-reporting mechanism. vSphere uses virtual CPU presentation and CPUID controls to determine which capabilities the guest can detect. A CPUID mask is a VM setting that controls which CPU feature bits are visible to the guest.
When NX/XD is masked, the guest sees no NX/XD or XD capability. The VM does not depend on that feature from the perspective of its guest-visible CPU. As a result, a destination host that lacks the feature is less likely to create a compatibility difference for that VM.
Hide Versus Expose NX/XD
| Configuration choice | What the guest sees | vMotion compatibility effect | Security implication | Typical use case |
|---|---|---|---|---|
| Expose NX/XD | The guest can detect the no-execute capability. | Requires eligible source and destination hosts to provide compatible support. | Preserves the CPU-provided protection for supported guest operating systems. | Normal choice when all possible hosts support the feature. |
| Hide or mask NX/XD | The guest sees no NX/XD or XD capability. | Can remove an NX/XD-specific compatibility difference between hosts. | The guest cannot use this CPU-provided protection through its visible CPU feature set. | Targeted workaround for a VM that must migrate across hosts with an NX/XD mismatch. |
When to Expose the Feature
Expose NX/XD when all hosts that may run the VM provide compatible support and the guest operating system can use it. This is normally the security-first choice because the guest retains access to non-execute memory protections.
When to Hide the Feature
Hide or mask NX/XD when a VM must migrate between otherwise compatible hosts that differ in this feature and the compatibility problem is specifically caused by that difference. Hiding the capability can improve migration flexibility, but it removes the feature from the guest's visible CPU set.
Use the narrowest practical scope. A common approach is to apply the CPUID mask only to affected legacy VMs rather than hiding NX/XD from every VM in the environment.
Assessing an NX/XD Mismatch
| Host capability state | VM CPUID presentation | Expected migration consideration | Recommended next step |
|---|---|---|---|
| All eligible hosts provide compatible NX/XD support. | NX/XD exposed. | The feature should not create a compatibility difference. | Keep the default exposed setting and validate normal vMotion compatibility. |
| Hosts differ in NX/XD support. | NX/XD exposed. | vMotion may report an execute-disable or NX/XD mismatch. | Review whether masking is acceptable for this VM. |
| Hosts differ in NX/XD support. | NX/XD hidden. | The guest no longer depends on the differing feature. | Recheck compatibility, then confirm the security and application impact. |
| Hosts differ in several CPU features. | Only NX/XD hidden. | Other feature differences may still block migration. | Review the complete compatibility result and address each remaining issue. |
Configure NX/XD in the vSphere Web Client
- Select the target virtual machine in the vSphere inventory.
- Open Edit Settings for the VM.
- Open the Virtual Hardware tab.
- Expand the CPU configuration section.
- Locate the CPUID Mask settings. The NX/XD exposure control is located in this area.
- Choose the appropriate option to hide or expose NX/XD for the VM.
- Save the VM configuration.
- Recheck vMotion compatibility between the affected source and destination hosts.
The exact labels can vary slightly between vSphere versions, but the configuration path is the VM's hardware settings, followed by CPU and CPUID mask controls. Treat the setting as a per-VM CPU presentation choice, not as a host hardware configuration.
Validate the Result
- Recheck compatibility: Run the vMotion compatibility check again for the intended source and destination hosts.
- Confirm guest visibility: Use the guest operating system's CPU or kernel feature reporting to confirm whether NX/XD is visible after the setting takes effect.
- Test migration: Where operational procedures allow, perform a controlled vMotion test rather than relying only on the configuration screen.
- Check the guest: Confirm that the guest OS remains healthy and that applications continue to operate as expected.
- Review security posture: If the feature was hidden, document that the guest no longer has this visible CPU protection and identify whether the setting should remain.
Depending on the VM and vSphere version, changing CPU presentation may require the VM to be powered off before the setting can take effect. Follow the management interface's prompt and your change-control process.
Practical Scenarios
Two Hosts Differ Only in NX/XD Support
A VM must move between two otherwise compatible ESXi hosts. One host exposes NX/XD support and the other does not. If the vMotion check identifies this feature as the blocking difference, masking NX/XD for that VM prevents the guest from depending on it and can remove that specific compatibility issue.
Security-First Placement
All hosts eligible to run a VM provide compatible NX/XD support. Leave the feature exposed so a capable guest OS can use non-execute memory protections. No compatibility workaround is needed.
Targeted Compatibility Workaround
Several legacy VMs need mobility across mixed CPU capabilities, but newer VMs can run only on hosts with compatible feature sets. Apply the CPUID mask only to the affected legacy VMs. Keep NX/XD exposed for other VMs whenever their placement requirements allow it.
Troubleshooting
vMotion Reports an NX/XD or Execute-Disable Compatibility Issue
The source and destination hosts may expose different CPU features to the VM. Review the VM's CPUID Mask configuration and decide whether hiding NX/XD is acceptable for that workload. Recheck compatibility after saving the change.
Migration Is Still Incompatible After Changing NX/XD
NX/XD may not be the only CPU mismatch. Review the complete vMotion compatibility result. CPU generation differences or other feature bits may require different host placement, a compatible CPU baseline, or another supported compatibility method.
The Guest Loses Expected No-Execute Protection
The NX/XD capability may have been hidden from the VM. If migration compatibility permits, expose the feature again and confirm that every eligible host supports it. Then verify the guest OS security settings.
Masking Was Expected to Make an Unsupported Host Fully Compatible
Masking affects only selected guest-visible CPU feature bits. It does not add hardware support to a destination host or resolve unrelated processor-generation differences. Use the compatibility report to identify all blocking features.
Exam-Relevant Notes
- AMD NX and Intel XD are equivalent no-execute processor capabilities.
- The feature marks selected memory regions as non-executable and helps limit some code-execution attacks.
- NX/XD is presented to the guest OS as a virtual CPU capability.
- Supported guests normally receive the capability by default.
- A CPUID mask hides a feature from the guest; it does not alter the physical ESXi host CPU.
- Hiding NX/XD can address a specific vMotion compatibility mismatch, but it removes the feature from the guest's visible CPU set.
- Expose NX/XD when compatible hosts support it and the guest can use it.
- Use the narrowest practical scope, usually the individual affected VM.
- A successful NX/XD change does not guarantee compatibility if other CPU differences remain.
For related configuration guidance, see Hide or Expose the NX/XD Bit.