Snapcenter 1.1,VSC 6.2 - workaround for bug 996792 "Failed to run a command New-NcSnapshotMulti

adambultman — Wed, 04 Jun 2025 16:14:25 GMT

If you're using SnapCenter 1.1 and the Netapp Virtual Storage Console for your VMware infrastructure, and you're having problems with backups, let my sordid tale help you in your hour of need. Should you be getting errors from VSC that it cannot perform a snapshot on your local SVM, with "failed to run a command New-NcSnapShotMulti", or if your snapmirrors will not update, reporting the error " Activity 'Replicating to Secondary' failed with error: Unable to find SnapMirror destination(s) for source " , look below.

Because in case you haven't noticed - there's not much documentation for Snapcenter and VSC apart from, "Install and then register X with Y". The Communities, useful tool they are, won't have everything you need to fix your backups. Netapp Bugs list the bug related to this problem - 996792 - but the information for it is internal-only, so you won't see this problem if you search in the bugs (as of this writing, anyway.)

Below are the steps I made in fixing my Snapcenter 1.1 and VSC 6.2 (and 6.2.1) problems, and backups that have not run (automatically) in many months.

This assumes that you have VSC 6.2 or VSC 6.2.1, and Snapcenter 1.1 installed. And that VSC and SnapCenter aren't run on the same server, because otherwise they slow to a crawl.

Also keep in mind that SnapCenter 1.1 *needs* to know your cluster IPs *and* your SVMs.

Also keep in mind that Virtual Storage Console must *NOT* know about your cluster IPs - SVMs only!

1. Make sure that any unused datastores on your VMware infrastructure are removed *if* they connect to an SVM that you do not want to appear in the VSC.   SVMs that show up as 'unknown' or are unmanageable break SC+VSC.

2. Remove "management" from any LIF on your SVMs that you do not want VSC to "see"; VSC will look at your various datastores and add management LIFs accordingly. LIFs that you have on an SVM that are connected to your ESX hosts but *not* reachable by your VSC server should not appear - and must be removed.
   - For instance: SVM "vmware_svm" has management access enabled via data-only network 10.10.10.55, but your VSC server is at 172.17.40.12, with no route inbetween.
   - The non-reachable SVM *should* be removable unless there is a mounted datastore from that SVM. See #1.

    - In some cases you can use an alternate IP address for management of the SVM. (See 8a)

3. On your VSC server, navigate to c:\Program Files\Netapp\Virtual Storage Console\etc\vsc

4. Move the file "vsc.xml" somewhere else. This has the SVM/cluster information for VSC.

5. Restart the Netapp Snapmanager for Virtual Infrastructure and the Virtual Storage Console services.

6. Re-log into the web client.

7. On the VSC tab, under "storage systems", your previous storage systems will be gone, and there will only be ones listed as 'unknown' and list the IP (and not the name.)

8. Identify the IP addresses listed in "storage systems", and match them to their SVMs:
   a) If an IP address belongs to an SVM that is *not* required for VSC, then delete it. If VSC needs it, you won't be able to. It's fine.

   a) If an IP address is listed for an SVM via an unreachable IP (See #2), modify that entry, and replace the unreachable IP with an IP address on that SVM that *is* reachable by your VSC server.

9. Any SVMs that need to be configured in VSC but were not already there by default, add them.

10. Once all SVMs have been added, wait until they show up with an alert for insufficient privileges. You can't avoid this, even if the user has enough privs - and even if you modify the connection, make sure the password is good, you save it, and it says, "OK" - it will revert to insufficient privileges anyway.

11. At this point, unless there are issues with Snapcenter, things should "work", despite the errors that VSC has for each of the SVMs.

12. If SnapCenter is the point of failure for your backup jobs, it *might* be that the SnapCenter server has simply lost it's brain; if you attempt to update SVM connection via the "settings" menu and it claims it cannot find/connect to/et the SVM, simply delete it, and re-add it. (Yes, that's right, delete and re-add. It's not right, but there you have it.)

13. If you have a backup job that persists in failing with NC-NewSnapShotMulti, you can also try editing the backup job, "removing" the backup entities (datastores) from the list, and re-selecting them. This worked for one persistently failing backup job. When I re-chose the datastores to back up, saved and ran it, it worked flawlessly.

Hopefully this will assist you. If you have any questions, bug me via email, and I'll see what I can do. I know far more about SC and VSC than I ever cared to know.

Re: Snapcenter 1.1,VSC 6.2 - workaround for bug 996792 "Failed to run a command New-NcSnapshotM

hariprak — Wed, 04 Jan 2017 05:57:03 GMT

Hi,

Thanks for sharing this information.

topic Re: Snapcenter 1.1,VSC 6.2 - workaround for bug 996792 "Failed to run a command New-NcSnapshotM in Data Protection

Snapcenter 1.1,VSC 6.2 - workaround for bug 996792 "Failed to run a command New-NcSnapshotMulti

Re: Snapcenter 1.1,VSC 6.2 - workaround for bug 996792 "Failed to run a command New-NcSnapshotM