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


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.


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.


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.




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.
   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 $ -nfshost $ -path $}


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) {$}


Joe Clarke said…
Or host profiles. : D Thanks for this post, it helped me figure out what was going wrong in my lab.
Anonymous said…
Thank you very much for this post, providing new hosts with the same datastores as existing hosts within a cluster was a breeze using your commands.

Popular posts from this blog

NSX-T: vCenter and NSX-T Inventory out of Sync (Hosts in vSphere not showing up in NSX-T)

MacOS: AnyConnect VPN client was unable to successfully verify the IP forwarding table modifications.

Azure VMware Solution: NSX-T Active/Active T0 Edges...but