Distributed IDPS Turbo engine (SCRX) fails to run after upgrading to NSX 4.2.2 (or later releases) and enabling the IDPS Turbo mode

Products

• VMware vDefend Firewall with Advanced Threat Prevention
• VMware vDefend Firewall

Issue/Introduction

After upgrading to NSX 4.2.2 (or later releases) and enabling the IDPS Turbo mode, the SCRX service datapath fails to come up,  even though the `nsx-scx` VIB is already installed.

Following symptoms are observed on an ESXi host:

• nsxcli -c get ids status returns "% A communication error occurred while processing the command."

• inf-cli get pods -n nsx-scx may show the nsx-security-services pod as RUNNING, but it is possibly not functioning correctly

• /var/run/log/nsx-syslog shows the following error messages repeatedly:

YYYY-MM-DDTHH:MM:SS.SSSZ Er(179) nsx-exporter[70758832]: NSX 70758832 - [nsx@6876 comp="nsx-esx" subcomp="agg-service" tid="70758918" level="ERROR" errorCode="MPA11011"] SCRX SDP: unixctl_client_transact() failed: cmd_result: (null), cmd_error: (null) 

YYYY-MM-DDTHH:MM:SS.SSSZ Er(179) nsx-exporter[70758832]: NSX 70758832 - [nsx@6876 comp="nsx-esx" subcomp="agg-service" tid="70758918" level="ERROR" errorCode="MPA11011"] SCRX SDP Stats failed 

YYYY-MM-DDTHH:MM:SS.SSSZ Wa(28) nsx-exporter[70758832]: 2025-08-12T08:07:36Z|06598|unixctl|WARN|error communicating with unix:/var/run/vmware/scx/sdp.ctl: End of file

• The service datapath in the SCRX continuously fails to come online. Following are the only two lines for the nsx-sdp logs that are observed in the nsx-syslog on every restart:

YYYY-MM-DDTHH:MM:SS.SSSZ In(7) nsx-sdp[78443061]: [crx@6876 progName="nsx-sdp" pid="-"] Use default syslog

YYYY-MM-DDTHH:MM:SS.SSSZ In(28) nsx-sdp[78443061]: [crx@6876 progName="nsx-sdp" pid="-"] NSX 203 - [nsx@6876 comp="nsx-sdp" subcomp="sdp" tid="203" level="INFO"] ServiceConfig: Successfully loaded config from /etc/vmware/scx/sdp.cfg

• Check if EVC(Enhanced vMotion Compatibility) is enabled on the cluster with the CPU mode set to Intel-Haswell generation. This older CPU mode is incompatible with SCRX. Steps to verify:
  • Browse to the vCenter UI.
  • Select the ESXi host cluster in the vSphere inventory.
  • Click the Configure tab, select VMware EVC.

 

• In /var/run/crx/infravisor-pod-#####-######/vmware.log, the guest CPUID is reported as Haswell EP/EN/EX, while the host CPUID is Ice Lake SP.

YYYY-MM-DDTHH:MM:SS.SSSZ In(05) vmx - guest vs. host CPUID guest family: 0x6 model: 0x3f stepping: 0x0

YYYY-MM-DDTHH:MM:SS.SSSZ In(05) vmx - guest vs. host CPUID *host family: 0x6 model: 0x6a stepping: 0x6

YYYY-MM-DDTHH:MM:SS.SSSZ In(05) vmx - guest vs. host CPUID guest codename: Haswell EP/EN/EX

YYYY-MM-DDTHH:MM:SS.SSSZ In(05) vmx - guest vs. host CPUID *host codename: Ice Lake SP


Environment

VMware NSX 4.2.2 and later releases

Cause

The root cause is that EVC (Enhanced vMotion Compatibility) is enabled on the ESXi cluster, with the CPU mode set to Intel-Haswell (or older) generation. This older CPU mode is incorrectly applied to SCRX and that leads to SCRX not initializing. 

Resolution

This issue will be fixed in an upcoming release. 

Workarounds:

Validate the EVC configuration on your ESXi Host cluster. Either switch it to a supported CPU (one that aligns with the ESXi compatibility guide) or disable EVC if possible. Please review this KB 31345  for more info on EVC.

Option 1: If EVC is not mandatory(i.e the hosts are going to remain with homogeneous processors in the cluster), go ahead and disable EVC.

Option 2: If EVC is a requirement, at the bare minimum set the CPU Mode as ‘Intel Broadwell generation’ or above for ESXi 8.0 u3