NFS Mapping to ESX and why you should use PowerCLI, not vCenter.

Summary:

Inserting a new host in an ESX Cluster and mapping an NFS share to it produced an interesting result.  vCenter showed 2 datastores w/ similar names.  1 w/ 48 hosts mapped to it and another w/ my 1 new host mapped to it.  The names were the same albeit one having a "(1)" appended to it.  Attempting to change the new one would result in error stating that a datastore already exists w/ that name.

Details:

Something as minor as an extra '/', servername.local vs. servername, or IP instead of name, makes ESX treat those mapped NFS shares as completely different even if they all point to the same end point.

Example:

Both of these are valid paths to a NFS share in ESX and they both connect to the same resource, but because of one having a FQDN ESX treats them as different shares completely.

netfs://servername.local/share

netfs://servername/share

Resolution:

Use PowerCLI to map NFS shares (or host profiles if you're licensed for them)

   1: #Use an ESX host that has your nfs paths mapped.

   2: $nfsshares = get-vmhost myfirstesxserver | get-datastore | where {$_.type -eq "NFS"} | Get-View

   3: #Now $nfsshares should have all your nfs pathing information.

   4:  

   5: #At this point I'm taking each entry in $nfsshares and 

   6: #mapping them to my new esx host

   7: $NewESXHost = Get-VMHost mynewESXServer

   8: Foreach ($nfsshare in $nfsshares)

   9: {$NewESXHost | New-Datastore -nfs -name $nfsshare.info.nas.name -nfshost $nfsshare.info.nas.remotehost -path $nfsshare.info.nas.remotepath}

Trick:

In the script above, if you want to see the nfs share information before you apply it do this after running the lines 1 - 3:

   1: Foreach($nfsshare in $nfsshares) {$nfsshare.info.nas}