WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
    • VMware Cloud Foundation 9.1
    • VMware Cloud Foundation 9.0
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple
You are here: Home / VCF Automation / Quick Tip: How to Identify Which Kubernetes Cluster Owns a vSphere Container Volume (PV)

Quick Tip: How to Identify Which Kubernetes Cluster Owns a vSphere Container Volume (PV)

06.25.2026 by William Lam // Leave a Comment

I was recently cleaning up some orphaned vSphere Container Volumes and while I was able to compare the Persistent Volumes (PV) IDs against the ones currently in use by a couple of Kubernetes clusters, I wanted to be 100% sure before removing them, especially since I planned bulk delete using PowerCLI’s Remove-CnsVolume cmdlet.

You can view all provisioned vSphere Container Volumes in the vSphere UI by navigating to vSphere Cluster->Monitor->Cloud Native Storage->Container Volumes. In addition to the volume details, you also get access to all of the associated metadata and labels, very similar to what you would see using kubectl, which is quite nice!


While reviewing the PV IDs in the UI, I noticed an attribute named Kubernetes Cluster, which appeared to identify the Kubernetes (K8s) cluster that owned the volume. How do I find this Kubernetes Cluster ID?

After a bit of trial and error, I discovered that the Kubernetes Cluster ID shown in the vSphere UI corresponds to the Cluster ID maintained by the vSphere CSI driver, making it easy to map a vSphere Container Volume back to its originating Kubernetes cluster.

Using PowerCLI, we can first fetch all unique k8s Cluster ID from available PVs by running the following:

$pv = Get-CnsVolume
$pv.ExtensionData.Metadata.ContainerCluster.ClusterID | Select-Object -Unique

Once I have the list of k8s Cluster ID, I can then login to k8s cluster in question and compare the ID, which you can run the following command:

kubectl -n kube-system get cm vsphere-csi-cluster-id -o yaml


In my case, I used this to validate both my VCF Management Services (VCFMS) and VCF Automation (VCFA) deployments, ensuring that none of the orphaned PVs I was about to remove were associated with either environment, since I had a recent re-deployment.

Once you have identified the k8s Cluster ID, you can use the following PowerCLI snippet to remove stale/orphaned PV volumes:

$clusterIdPvToRemove = "dc88861b-393b-4b0e-8b2a-db5416b3f02d"

$pv | where {$_.ExtensionData.Metadata.ContainerCluster.ClusterID -eq $clusterIdPvToRemove} | Remove-CnsVolume -Confirm:$false

Categories // VCF Automation, VMware Cloud Foundation, VMware vSphere Foundation, vSphere Kubernetes Service

Thanks for the comment!Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Quick Tip: Reducing High CPU Utilization in VCF Automation (VCFA) on AMD Zen4/Zen5 CPUs 08/12/2026
  • VCF 9.1 - Quick Tip: Optimized Workflow for Configuring Distributed Transit Gateway (DTGW) with NSX Virtual Network Appliance (VNA) 08/11/2026
  • Quick Tip: Selective ESX Host Patching in VCF 9.1 08/10/2026
  • Playing with Zero Touch Provisioning (ZTP) in vSphere 9.1 using an ASUS NUC 08/07/2026
  • Quick Tip: Automating ESX System Resource Pool Workaround Prior to 8.0 Update 3g 08/06/2026
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.

To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2026

Loading Comments...