Script - Create Source and Destination volumes, export NFS and mount to ESXi hosts

[Tracy_L]

We've got an odd problem that's been going on for a while.  When we create a new nfs vol on Netapp (ontap 8.2.3), we must wait 30-40 minutes before we're able to add it to vCenter.  Trying to add it immediately produces an "access denied" error.  If we wait 30 minutes or so, it adds to vCenter just fine.

No changes to ontap (8.2.3 is the version installed with the netapp and we've not done any updates yet)

NFS3

vcenter and vsphere 6.0 (u1, 2 and 3)

We're adding the storage to vcenter using IP address (server name field) of the netapp controller.

The namespace and export policy seems obviously correct, since it does eventually mount with no changes.  Export policy is in use by over 100 other nfs vols/data stores.

Anyone seen this before?

Thank you!

[mbeattie]

Hi Tracy,

I've seen this issue before, are you using load sharing mirrors for you vserver root volume? If so have you tried invoking a snapmirror update of your vserver root LSM volume, then mount trying to add the volume as an NFS datastore to your ESX hosts? To check if your vserver hosting the NFS volumes for your vsphere datastores is using a load sharing mirror or the root volume (namespace) SSH to your cluster and using the following commands as an example:

cluster1::> snapmirror show -vserver vserver1
                                                                       Progress
Source            Destination Mirror  Relationship   Total             Last
Path        Type  Path        State   Status         Progress  Healthy Updated
----------- ---- ------------ ------- -------------- --------- ------- --------
cluster1://vserver1/vserver1_root
            LS   cluster1://vserver1/vserver1_root_m1
                              Snapmirrored
                                      Idle           -         true    -

cluster1::> snapmirror update -source-path vserver1:vserver1_root -destination-path vserver1:vserver1_root_m1
[Job 2772] Job is queued: snapmirror update of destination "cluster1://vserver1/vserver1_root_m1".

Also you can use WFA to automate this task and integrate with vSphere too. Might be an option for you instead of a script, you can call WFA workflows using a script via a REST API if you really want to stay with CLI script option, the benefit of using WFA for this is that your automation process is centralised, logged, auditable etc. Please let me know if you have any questions.

/Matt