How to figure out where data disks in vCenter point back to on Netapp SAN?

[19rellimcm37]

I'm new with Netapp along with SAN Technology, so I apologize in advance. 

We have a Netapp SAN, where both controllers failed.  We got that fixed, however we are dealing with the fallout from it. 

I have a RHEL5 VM managed by vCenter, however we I tried to boot it up, the disks were scrambled and it would not successfully boot up.  We are going to restore from backup and then just build a new VM. 

Doing some research, I wasn't using UUIDs under /etc/fstab, so that might have been one of the reasons the disks got scrambled. 

My question to you all is, is there a way for me to try and figure out how to map back to those disks correctly either from the SAN or from the VM in order to try and rebuild this server? 

Also is there a way with the UUID from Red Hat to see what LUNs these point to?

Hopefully what I'm asking makes sense.

thanks

[kkemnitz]

@19rellimcm37

Do these mapped disks happen to be Physical Raw Device Mappings (pRDMs)? If so, you should be able to use the NetApp Host Utilities Kit for Linux from https://mysupport.netapp.com/NOW/cgi-bin/software/ under "Host Utilities - SAN". Documentation is available for this kit at https://mysupport.netapp.com/documentation/productlibrary/index.html?productID=61343#30480.

Packaged into the kit is a utility called "sanlun". You can run a command similar to the following to provide you the block device and how it corresponds to the LUN name and WWID in SANtricity or SANtricity System Manager:

[root@localhost ~]# sanlun lun show -v
device host lun
controller lun name filename adapter protocol size product
---------------------------------------------------------------------------------------------------------------
ICTM1519S02C2 RDM_87 /dev/sdh host2 iSCSI 2g E-Series
Controller node address: iqn.1992-08.com.netapp:2752.60080e50003416dc0000000056a69c1a
Controller port address: iqn.1992-08.com.netapp:2752.60080e50003416dc0000000056a69c1a,t,0x0102
Controller Firmware Version: 08.30.XX.XX (Date: 08/07/17)
Controller target port: Controller-B, Port 4
Controller LUN Ownership: Preferred Path, Owning Controller
Controller IPv4 Management: 10.113.116.159
device host lun
controller lun name filename adapter protocol size product
---------------------------------------------------------------------------------------------------------------
ICTM1519S02C1 RDM_54 /dev/sdi host2 iSCSI 2g E-Series
Controller node address: iqn.1992-08.com.netapp:5700.600a098000af51920000000058f15d26
Controller port address: iqn.1992-08.com.netapp:5700.600a098000af51920000000058f15d26,t,0x0201
Controller Firmware Version: 08.30.XX.XX (Date: 08/07/17)
Controller target port: Controller-B, Port 4
Controller LUN Ownership: Preferred Path, Owning Controller
Controller IPv4 Management: 10.113.116.157

[19rellimcm37]

The disks were formatted in VMFS and not Raw Disks.  Not sure if that utility will work or not for that.

[kkemnitz]

The utility will not work for virtual disks mapped to the virtual machine. You may have to browse the individual datastores and look beneath the folder named for the virtual machine that is being blown away and restored. The individual .vmdk files will be named "-flat.vmdk" and ".vmdk". Choose the ".vmdk" to map back to the host, which is essentialy a descriptor file that points to the "-flat.vmdk" that contains the data.

[19rellimcm37]

Ok, I'll have to look into this and see what we can do.

thanks