With the introduction of the vSphere Container Storage Interface (CSI) 2.1, it looks like the previous method outlined by Cormac Hogan no longer applies when looking to map between a vSphere Container Volume (CV), which is a vSphere construct to the underlying Persistent Volume Claim (PVC), which is a Kubernetes construct.
William Arroyo, a K8s Solution Engineer recently noticed this behavior change and was asking if there was a way to use PowerCLI to still perform this look up. Given I had provided the original PowerCLI snippet on Cormac's blog, I was curious myself and since I had just rebuilt my vSphere with Tanzu environment, I figured I take a quick look to see where this new information might now be placed.
I did also want to mention that you can easily find this information using the vSphere UI by just clicking on the "Details" box next to the PVC
With the latest PowerCLI 12.1 release, we have a number of Cloud Native Storage (CNS) cmdlets that we can leverage and after a quick minute of poking around, this new information can be found using the Get-CnsVolume cmdlet and using the ExtensionData property to get more detailed properties.
You can specify either the filename and/or ID to the cmdlet. In my example, the vSphere CV has label of pvc-31fc30d4-a5a2-438d-9f07-b90e0a67d3ab and we just need to pass that using the following command:
(Get-CnsVolume -Name pvc-31fc30d4-a5a2-438d-9f07-b90e0a67d3ab).ExtensionData.Metadata
The Metadata.EntityMetadata is what we are after and as you can see from the output, we can see both the PVC ID which is pvc-f8777fc1-8408-423b-8cd0-e30907512270 and even the PVC Label which is called pvc-test
If we now take a look from the Kubernetes perspective and using kubectl to retrieve our PVC using:
kubectl get pvc
We can see that the information matches.
If we wanted to get information about the the exact VMDK path, we can use the Get-VDisk cmdlet and pass in the vSphere CV
Get-VDisk | select Name, Filename
Thanks for the comment!