Orphaned PVC Objects Remaining in vSAN After SSP Deletion

Products

• VMware vDefend Firewall with Advanced Threat Prevention

Issue/Introduction

After following the official procedure to delete a Security Services Platform (SSP) instance or SSP Installer (SSPI), Persistent Volume Claim (PVC) objects may remain as orphaned entries in the vSAN virtual objects inventory. These leftover objects can trigger vSAN health warnings for high object usage and must be manually remediated before redeploying SSP to another cluster.

• vSAN health dashboard reports warnings related to high virtual object usage.
• After completing SSP deletion steps, the vSAN virtual objects count remains unchanged (e.g., ~8,595 objects).
• CLI verification (kubectl / SSP CLI) shows no active PVC resources or SSP instances.
• vCenter UI shows 18–20 PVC entries inside a container namespace.
• Objects display a "(Missing)" tag in their path name and the namespace UUID no longer exists.
• Running esxcli vsan debug object list confirms orphaned objects with missing paths.

Environment

• SSP 5.x
• Kubernetes disabled on the source cluster after SSP removal

 

Cause

When an SSP instance is deleted without first removing associated Persistent Volume Claims (PVCs) through the Kubernetes / SSP management layer, the underlying vSAN First Class Disk (FCD) objects in the fcd namespace are not cleaned up. These FCD-backed vmdk objects persist in vSAN storage even though the Kubernetes control plane no longer tracks them.

 

This can be compounded by:

• Moving the fcd folder between datastores or clusters using the vCenter Datastore Browser instead of the proper API/management tooling.
• Disabling Kubernetes on the cluster before removing PVC resources, leaving the storage layer unaware of the expected cleanup.
• Transient I/O errors or datastore inaccessibility during deletion that leave vSphere inventory out of sync with the datastore backing metadata.

 

Resolution

The root cause of this issue is within the vSAN storage layer and is outside the scope of SSP support. Remediation requires engagement with the vSAN storage team and, if needed, Broadcom support.

Additional Information

Prevention: 

• Always remove PVCs and SSP-managed storage resources via the SSP management interface or Kubernetes API before disabling Kubernetes or deleting the SSP instance.
• Follow the official deletion sequence: remove workloads → remove PVCs → remove SSP instance → remove SSPI.
• Avoid moving the fcd folder using the vCenter Datastore Browser; use the vStorageObjectManager API for FCD operations.
• After any SSP removal, validate vSAN object counts before redeploying to a new cluster.