Script - Create Source and Destination volumes, export NFS and mount to ESXi hosts
2018-02-07 08:22 AM
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)
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?
1 REPLY 1
Re: Script - Create Source and Destination volumes, export NFS and mount to ESXi hosts
2018-02-07 02:45 PM
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.
If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.