Turbo/SCRX infravisor POD fails to start when vmsyslog Logdir Is Modified
search cancel

Turbo/SCRX infravisor POD fails to start when vmsyslog Logdir Is Modified

book

Article ID: 430768

calendar_today

Updated On:

Products

VMware vDefend Firewall with Advanced Threat Prevention VMware vDefend Firewall

Issue/Introduction

  • The infravisor-pod shows a zero MAC address:
    [root@ESXi:~] net-stats -l | grep -E "infravisor|PortNum"
    PortNum          Type SubType SwitchName       MACAddress         ClientName
    ######2           5       0 DvsPortset-#     00:00:00:00:00:00  infravisor-pod.eth0

 

  • Log directory is configured to a location other than /scratch/log:
    [root@ESXi:~] grep "logdir=" /etc/vmsyslog.conf
    logdir=/scratch/log
    logdir=/vmfs/volumes/##########               <<<<< Log directory other than /scratch/log is configured

 

  • In NSX 4.2.3.3, the following alarm may be observed:
The security services container on host node #########-####-####-####-##########is down. Traffic will not be subject to IDPS, and malicious traffic could go undetected. For L7 traffic, App ID or FQDN based rules may not match.
  • Restarting the /etc/init.d/nsx-scx-### service does not resolve the issue.
  • /var/run/log/vmkernel.log shows:
2026-##-##T##:##:##.###Z In(##) vmkernel: cpu##:#####)Net: ####: associated dvPort dynamoPort########## with portID 0x#######
2026-##-##T##:##:##.###Z In(##) vmkernel: cpu##:#####)VmkAccess: ###: python3: running in nsxDatapathCtrsDom(81): socket = /var/run/nscd/socket (unix_stream_socket_connect): Access denied by vmkernel access control policy
2026-##-##T##:##:##.###Z In(##) vmkernel: cpu##:#####)VmkAccess: ###: python3: running in nsxDatapathCtrsDom(81): socket = /dev/log (unix_stream_socket_connect): Access denied by vmkernel access control policy
  • /var/run/log/nsx-scx.log on ESXi shows:
2026-##-##T##:##:##.###Z No(###) nsx-scx[###]: NSX ### - [nsx@6876 comp="nsx-scx" subcomp="scx-fs-server" tid="#### level="NOTICE"] Error in admission control
2026-##-##T##:##:##.###Z Wa(###) nsx-scx[###]: NSX ### - [nsx@6876 comp="nsx-scx" subcomp="scx-esx-proxy" tid="####" level="WARNING"] ep_map_vsock: r failed (Invalid argument)
2026-##-##T##:##:##.###Z Wa(###) nsx-scx[###]: NSX ### - [nsx@6876 comp="nsx-scx" subcomp="scx-esx-proxy" tid="####" level="WARNING"] do_handle_listener: error while mapping sockets, listener: 17, closing fd:19
2026-##-##T##:##:##.###Z Wa(###) nsx-scx[###]: NSX ### - [nsx@6876 comp="nsx-scx" subcomp="scx-esx-proxy" tid="####" level="WARNING"] do_handle_listener: error while mapping sockets, listener: 17, closing fd:19
2026-##-##T##:##:##.###Z No(###) nsx-scx[###]: [crx@6876 progName="nsx-scx" pid="-"] NSX 56 - [nsx@6876 comp="nsx-scx" subcomp="scx-fs-client" tid="61" level="NOTICE"] vsock_receive_response: bytes_read 0. Peer has closed the connection.Trying re-init of socket. dir: /python_nsx_monitoring

 

  • Secondary symptoms (since the infravisor pod is not up), /var/run/log/nsx-syslog shows:
2026-##-##T##:##:##.###Z Er(##) nsx-exporter[###]: NSX ### - [nsx@6876 comp="nsx-esx" subcomp="agg-service" tid="#####" level="ERROR" errorCode="MPA11011"] SCRX SDP: unixctl_client_transact() failed: cmd_result: (null), cmd_error: (null)
2026-##-##T##:##:##.###Z Er(##) nsx-exporter[###]: NSX ### - [nsx@6876 comp="nsx-esx" subcomp="agg-service" tid="#####" level="ERROR" errorCode="MPA11011"] SCRX SDP Stats failed

 

Environment

The issue only impacts the following versions with Turbo/SCRX deployment

vDefend Firewall with ATP 4.2.2.x
vDefend Firewall with ATP 4.2.3.x

Cause

The CID helper script fails to start properly when vmsyslogd is configured to use a log directory other than /scratch/log.

The secpolicy for the nsxScxCid domain only allows the script to use /scratch/log. When logs are redirected to another location (for example, /vmfs/volumes/...), the CID helper cannot access the required resources, resulting in the infravisor-pod not coming up

Resolution

This issue will be resolved in the upcoming NSX release  

Workaround:

  1. Identify the nsxScxCid Domain using /bin/secpolicytools -d | grep nsxScxCid 

Example:    
    [root@ESXi:~] /bin/secpolicytools -d | grep nsxScxCid 
    Domain Name: nsxScxCid-25171319 Domain ID :125 Enforcement Level: enforcing
    
Note the nsxScxCid-##**## value.


    2. Change Enforcement Level to Warning using esxcli system secpolicy domain set -n nsxScxCid-##**## -l warning
    The ##**## number from command 1 must match in the command below. The 25171319 represents the NSX build number. Each NSX version will have a different build number.

Example:    
    [root@ESXi:~] esxcli system secpolicy domain set -n nsxScxCid-25171319 -l warning

    
    3. Restart the nsx-scx Service using /etc/init.d/nsx-scx-###### restart 

Example:
    [root@ESXi:~] /etc/init.d/nsx-scx-25171319 restart


    4. Verify infravisor-pod is running with a non-Zero MAC

Example:
    [root@ESXi:~] net-stats -l | grep -E "infravisor|PortNum"
    PortNum          Type SubType SwitchName       MACAddress         ClientName
    #####15           5       0 DvsPortset-#     00:0c:29:##:##:##  infravisor-pod.eth0


This workaround persists across ESXi reboots.

PR 3658712

Powered by Wolken Software