Subscribe
Accepted Solution

VSC 4.0 / SMVI breaks after NFS datastore vol rename

Curious if there's going to be any way around this other than manually unmounting and remounting each datastore in vCenter. Have a customer that is running VSC 4.0 and DOT 7.3.4P2 and they renamed a bunch of their datastores in vCenter and then went and renamed the volumes on the filers as well. Luckily that had nfs.export.auto-update set to on so they didn't drop the datastores from VMware. The problem is that when SMVI queries vCenter for datastore names and paths, vCenter returns the new datastore name along with the old path. When SMVI queries the controller for the export path it gets a FAIL returned since that vol path no longer exists since the vol was renamed. Is there any way to fix this so that SMVI can correlate the datastores correctly other than touching every single datastore manually in vCenter and updating its path?

Below is the log excerpt from one of the datastores:

2012-04-16 15:05:18,541 [discoverDatastores:2bb3a900458aca21f093b98fb4a882b2:] DEBUG - ZEPHYR-10001: Executing ZAPI request "nfs-exportfs-storage-path" to "netapp2.xxxx.com":

<nfs-exportfs-storage-path>

          <pathname>/vol/ATA_NFS_win7</pathname>

</nfs-exportfs-storage-path>

2012-04-16 15:05:18,770 [discoverDatastores:2bb3a900458aca21f093b98fb4a882b2:] DEBUG - ZEPHYR-10003: ZAPI call "nfs-exportfs-storage-path" to "netapp2.xxxx.com" returned error: No actual-pathname for /vol/ATA_NFS_win7 (13114)

2012-04-16 15:05:18,771 [discoverDatastores:2bb3a900458aca21f093b98fb4a882b2:] ERROR - Failed to find NFS export path /vol/ATA_NFS_win7 for datastore aggr2_win7 on storage system 172.25.4.48. NFS datastores must be exported from a Data ONTAP storage system.

com.netapp.common.zapi.ZAPIExecuteException: No actual-pathname for /vol/ATA_NFS_win7 (errno=13114)

          at com.netapp.common.zapi.AbstractZAPIExecutor.execute(AbstractZAPIExecutor.java:70)

          at com.netapp.common.zapi.ZAPIRunner.run(ZAPIRunner.java:58)

          at com.netapp.common.zapi.ZAPIRunnerWrapper.run(ZAPIRunnerWrapper.java:54)

          at com.netapp.smvi.task.vmware.util.DatastoreMapper.createNfsDatastore(DatastoreMapper.java:362)

          at com.netapp.smvi.task.vmware.util.DatastoreMapper.createDatastore(DatastoreMapper.java:242)

          at com.netapp.smvi.task.vmware.util.DatacenterUtil.fillDatastoresOfDC(DatacenterUtil.java:158)

          at com.netapp.smvi.task.vmware.discovery.DiscoverDatastores.execute(DiscoverDatastores.java:46)

          at com.netapp.common.flow.TaskInstanceTemplate.execute(TaskInstanceTemplate.java:336)

          at com.netapp.common.flow.Operation.executeCurrentStack(Operation.java:146)

          at com.netapp.common.flow.Operation.execute(Operation.java:61)

          at com.netapp.common.flow.Threadpool$OperationThread.run(Threadpool.java:257)

Caused by: netapp.manage.NaAPIFailedException: No actual-pathname for /vol/ATA_NFS_win7 (errno=13114)

          at netapp.manage.NaServer.invokeElem(NaServer.java:670)

          at com.netapp.common.zapi.AbstractZAPIExecutor.execute(AbstractZAPIExecutor.java:52)

          ... 10 more

Re: VSC 4.0 / SMVI breaks after NFS datastore vol rename

using -actual in the export might be a band-aid for this... brute force but can use the old name of the mount to the new path.  So a new volume name but the old volume name as the mount path.  The auto export update is needed also for when volumes are flexcloned...smvi doesn't create an export but uses the one auto created from what I remember (may have changed though with vsc)

Re: VSC 4.0 / SMVI breaks after NFS datastore vol rename

-actual worked liked a charm in the lab. It's a band-aid fix for sure, but it makes less work for the situation on the customer's behalf. Thanks for the idea!

Re: VSC 4.0 / SMVI breaks after NFS datastore vol rename

Brute force is sometimes a good fit J

Re: VSC 4.0 / SMVI breaks after NFS datastore vol rename

What about getting SMVI to do a full rescan of the datastores and ESX hosts?