nsx-node-agent pods stuck in CLBO post upgrading OC to 4.20

Products

• VMware NSX

Issue/Introduction

• nsx-node-agent pods are stuck in CrashLoopBackOff state post upgrading Openshift to 4.20.
• Openvswitch was masked per KB 406441 on previous version.
• Below errors are observed in the nsx-ovs container logs:
  
  2026-08-19T20:58:23Z worker NSX 1 - [nsx@6876 comp="nsx-container-node" subcomp="NSX-OVS" level="INFO"] .usr.local.bin.start_ovs (Re)activated connection: ens192-ovs-port
2026-08-19T20:58:23Z worker NSX 1 - [nsx@6876 comp="nsx-container-node" subcomp="NSX-OVS" level="ERROR"] .usr.local.bin.start_ovs Failed to activate connection ens192-ovs-intf
  
  
• The host (worker node) directory's on-disk label does not match what policy expects.
  matchpathcon (what policy says it should be) disagrees with ls -Zd (what it actually is):
  
  [root@worker nsx-ujo]# matchpathcon /var/run/openvswitch
/var/run/openvswitch    system_u:object_r:openvswitch_var_run_t:s0

[root@iworker nsx-ujo]# ls -Zd /var/run/openvswitch
system_u:object_r:container_var_run_t:s0 /var/run/openvswitch
  
  
  

Environment

Openshift 4.20

VMware NSX

Cause

/var/run/openvswitch is a non-persistent hostPath volume, created directly by the container runtime/kubelet on the node the first time it is needed — not by the native openvswitch package. When this directory is created by openvswitch.service running on the host upon boot, it labels it openvswitch_var_run_t  as per the policy shipped in the openvswitch-selinux-extra-policy package. However, when openvswitch.service is masked (per Article 406441), the directory gets created by the container runtime when the nsx-ovs container's hostPath volume is first mounted, and ends up labeled container_var_run_t.

NetworkManager (SELinux domain NetworkManager_t) does not have policy permission to write to a sock_file labeled container_var_run_t. Since db.sock (created by nsx-ovs under this mislabeled directory) inherits that label, NetworkManager cannot connect to the OVS database, and cannot activate the OVS uplink connection profile.

Resolution

If you're already on Openshift 4.20 or higher, Perform these steps in order, on every affected node:

• Relabel the directory on each worker node by running the below command inside the worker nodes (oc debug node/<>)
  chcon -Rv system_u:object_r:openvswitch_var_run_t:s0 /var/run/openvswitch/
  
  Expected output (note: with -R, chcon only reports the top-level path once, not every file underneath it — this is normal and does not mean only the directory itself was relabeled; the whole tree is relabeled recursively):
  
  [root@worke nsx-ujo]# chcon -Rv system_u:object_r:openvswitch_var_run_t:s0 /var/run/openvswitch/
changing security context of '/var/run/openvswitch/'

NOTE: /var/run is tmpfs. This relabel does not survive a reboot — it only unblocks the node right now. Complete Steps 2–3 for a durable fix.

• Unmask the native OVS service by running the below command:
  systemctl unmask openvswitch
  
  This is what allows openvswitch.service to run again on the next boot, which is what lets it correctly self-label /var/run/openvswitch before nsx-ovs ever needs it — permanently preventing the mislabeling described above from recurring.
  
  

If the current version is Openshift 4.19 or lower, and upgrading to 4.20 or higher:

• Unmask the openvswitch service before upgrading the OC node using below:
  
  systemctl unmask openvswitch