https://community.netapp.com/t5/VMware-Solutions-Discussions/How-to-obtain-the-Secondary-LUN-IDs-when-using-Protocol-End-Points-to-connect-to/m-p/157287#M9726 <P>Hello,</P> <P>I am trying to understand how Protocol End Points work in the context of deploying VVol Datastores over a fibrechannel SAN network. I have successfully deployed a VVol Datastore on my FAS-8040 using the VASA Provider with the required storage profiles for my testing. I was also able to create a VM and added that to the VVol Datastore, after associating the storage policies of its files to the created VVol datastore. When I power on the VM and analyze the trace captures, I see that all the communication happens only to the PE LUN, which I believe is correctly working. But, I was curious to know how the ESX Hosts learn about the other Sub LUNs for the metadata(config), vmdk and the swap LUNs created inside the Virtual Volume. More importantly, I was curious to know if the ESX Hosts learn about the Sub or the Secondary LUN Ids.&nbsp; From the screenshots placed below, the vmdk LUNs do not appear to have a LUN ID which is also confusing to me, since I thought there a binding of the Secondary LUN ID to a Protocol End Point LUN. Where can I find the Secondary LUN ID to PE binding using CLI or system Manager?</P> <P>&nbsp;</P> <P>&nbsp;Also, as part of my investigation, on one of the Inquiry exchanges to the PE LUN, I see that the VPD contains a LUN with the SCSI name "naa.600A0980383035694F2B495A67654356". This has also been attached in the screenshots below. However, when I look up the available LUNs through system manager, I dont see this LUN listed in the vServer that hosts my VVols. I was&nbsp; curious to know what this LUN could be be. Lastly, I was also interested to know how do the ESX Hosts bind to the vmdk LUNs, if they dont send any Report LUNs or Inquiry commands to these LUNs.&nbsp; I would really appreciate your feedback with this.</P> Wed, 04 Jun 2025 11:03:51 GMT k2prakash 2025-06-04T11:03:51Z https://community.netapp.com/t5/VMware-Solutions-Discussions/How-to-obtain-the-Secondary-LUN-IDs-when-using-Protocol-End-Points-to-connect-to/m-p/157287#M9726 <P>Hello,</P> <P>I am trying to understand how Protocol End Points work in the context of deploying VVol Datastores over a fibrechannel SAN network. I have successfully deployed a VVol Datastore on my FAS-8040 using the VASA Provider with the required storage profiles for my testing. I was also able to create a VM and added that to the VVol Datastore, after associating the storage policies of its files to the created VVol datastore. When I power on the VM and analyze the trace captures, I see that all the communication happens only to the PE LUN, which I believe is correctly working. But, I was curious to know how the ESX Hosts learn about the other Sub LUNs for the metadata(config), vmdk and the swap LUNs created inside the Virtual Volume. More importantly, I was curious to know if the ESX Hosts learn about the Sub or the Secondary LUN Ids.&nbsp; From the screenshots placed below, the vmdk LUNs do not appear to have a LUN ID which is also confusing to me, since I thought there a binding of the Secondary LUN ID to a Protocol End Point LUN. Where can I find the Secondary LUN ID to PE binding using CLI or system Manager?</P> <P>&nbsp;</P> <P>&nbsp;Also, as part of my investigation, on one of the Inquiry exchanges to the PE LUN, I see that the VPD contains a LUN with the SCSI name "naa.600A0980383035694F2B495A67654356". This has also been attached in the screenshots below. However, when I look up the available LUNs through system manager, I dont see this LUN listed in the vServer that hosts my VVols. I was&nbsp; curious to know what this LUN could be be. Lastly, I was also interested to know how do the ESX Hosts bind to the vmdk LUNs, if they dont send any Report LUNs or Inquiry commands to these LUNs.&nbsp; I would really appreciate your feedback with this.</P> Wed, 04 Jun 2025 11:03:51 GMT https://community.netapp.com/t5/VMware-Solutions-Discussions/How-to-obtain-the-Secondary-LUN-IDs-when-using-Protocol-End-Points-to-connect-to/m-p/157287#M9726 k2prakash 2025-06-04T11:03:51Z