SC 4.0 - Unable to create resource groups

[DavidDAVE]

Dear all,

First of all, thanks a lot for your time on reading this post!

I was working with VSC6.2, but we have recently upgrade ONTAP in our FAS8040 from 8.3.4 to 9.1, and after that, our VSC jobs kept working, but they werent capable of updating the snapmirror relationship against our secondary FAS8040.

So, let's move forward.

- I deployed a new VM with SnapCenter 4.0 in my main vCenter. My idea is that all VSCs from my four vCenters are controlled from there. And all backups jobs, policies, etc.

- I unninstalled VSC6.2 for my secondary vCenter.

- Afterwars I learned that VSC 7.X is no longer in charge of backups, but anyway i deployed one in one of my secondary vCenters, for test porpouses. I really like applying best practices for NFS / MPIO /adapters so easily :).

- In SC 4.0 I added all SVMs from my two cabins, main and secondary.

- In SC.40 I added a new host for vsphere, choosed a win VM in my secondary vCenter, added win credentials (AD admin). After a while, all was deployed, incluiding SnapCenter Plugín for VMware vSphere.

- There I could see that my SVM where alredy deployed in "Storage Systems" tab, pulled from SnapCenter.

- There I could create a new policy, which I could see was pushed to the SC (settings - user access - policy). The strange thing is that in SC I couldnt see them on settings - policies...

My problem comes when I wan to create a Resource Group with a single datastore, using the newly created policy. I can choose it on the wizzard, but when I finish the task, I got errors:

- Resource Group creation failed : Unable to find host (X.X.X.X). This address if the IP from the server which i choosed to deploy the Plugin for vSphere.

- In "Monitor" tab in SC I can see the job listed as failed, with the same message.

- In "Monitor" tab, "Logs" subtab, I can see the following related messages:

1. WARN SnapManagerWeb PID=[3388] TID=[223] Host X.X.X.X not found in nsm 
2. ERROR SnapManagerWeb PID=[3388] TID=[223] Failed to find host (X.X.X.X). Please check the host is up and running or check the firewall settings. No such host is known
3. ERROR SnapManagerWeb PID=[3388] TID=[223] System.Exception: Unable to find host (X.X.X.X) at SnapManager.SMSDAL.ProtectionGroupDAL.MapProtectionGroupResource(IEnumerable`1 hostResourceMaping, SmConfiguration pgConfiguration, nsm_protection_group pg, SmSn

About error 1 I found googling that NSM is the database installed during SC deployment. About error 2 I have double checked FW in all win machines (SC and Plugin VMs), and all firewalls in the middle (all traffic allowed). I suppose that vapps (vCenter and VSC) have all needed ports opened by default. About error 3 I found nothing.

I'm stucked at this point, and really appreciate any help.

Kind regards,

David

[JesseEverett]

After I went into settings in the vsphere snapcenter plugin, I confirmed the settigns I had before, the flash client will freeze up for about 5 min applying the settings but then it worked for me.

[COSNA2]

We have a similar setup:

1. ONTAP 9.1 P8

2. We have multiple arrays i.e. 8020's, 8040's, AFF, etc.

3. VMware vCenter 6.0 Update 3(e)

4. Virtual Storage Console 6.2.1P1D2 (Plan in the works to upgrade to 7.0)

5. SnapCenter 4.0 (just recently installed to replace SMVI)

We are stuck with the following error logged in the newly installed SnapCenter in the logs:

ERROR SnapManagerWeb PID=[3388] TID=[223] Failed to find host (X.X.X.X). Please check the host is up and running or check the firewall settings. No such host is known

When we attempt to create a resource group for one of our sites (remote, 8020), we get an error at one (1) of our 3 sites: "Some entities are not SnapCenter compatible." while the other sites (remote, 8040, AFF) work fine...

When reviewing the logs in SnapCenter, the following error is logged: "Failed to get the storage system for host resource"

[AshishGupta]

The reasons when you can run into issue "Some entities are not SnapCenter compatible." are listed below:

• VMDKs are on unsupported storage; for example, on an ONTAP system running in 7-Mode or on a non-ONTAP device.
• A datastore is on NetApp storage running Clustered Data ONTAP 8.2.1 or earlier
• SnapCenter 3.0 supports ONTAP 8.2.2 and later. SnapCenter versions 3.0.1 and 4.0 support ONTAP 8.3.1 and later. The SnapCenter Plug-in for VMware vSphere does not perform compatibility checks for all ONTAP versions; only for ONTAP versions 8.2.1 and earlier. Therefore, always see the Interoprability Matrix Tool (IMT) for the latest information about SnapCenter support.
• A shared PCI device is attached to a VM.
• A preferred IP is not configured in SnapCenter.
• You have not added the SVM management IP to SnapCenter.
• The SVM is down.
  

Can you check if you are running into any of these?

The corrective actions are pretty obvious but nevertheless listing it here:

• Make sure the SVM is running.
• Make sure that the storage system on which the VMs are located have been added to the SnapCenter Plug-in for VMware vSphere inventory.
• Make sure the SVM is added to SnapCenter. Use the Add storage system option on the SnapCenter GUI or on the VMware vSphere web client GUI.
• If there are spanning VMs that have VMDKs on both NetApp and non-NetApp datastores, then move the VMDKs to NetApp datastores.

[COSNA2]

We resolved our issue two (2) weeks ago; however, we scrapped Snap Center 4.0 out of our virtual infrastructure at this time.

Our issue was that we somehow missed adding two (2) backup SVM targets into Snap Center 4.0 interface. Once this was realized, we had no further issues in terms of the Resource Groups.

Now, for the reason we scrapped Snap Center 4.0...

NetApp VSC 6.2.1P1D2 is not compatible with Snap Center 4.0. As such, it is not recommended to run both in the same vCenter instance. When we contacted NetApp Support, we were told that we would need to upgrade to NetApp VSC 6.2.1P1D6 in order for things to work properly. So we followed the advice of support....

A week later, we started exhibiting problems with our VSC. It would disappear out of our vCenter environment completely. Although in the Windows Client the plug was showing as registered, the web client it was completely missing with only the Snap Center 4.0 plugin available. Our VSC SMVI snapshots however were unaffected but we were unable to manage our VSC.

After several interations with removing and re-registering the VSC plugin it would come back and the next day, it would disappear.

Further interaction with NetApp support turned out that not even P1D6 is supported to co-exist with Snap Center 4.0 in the same vCenter instance.

This basically put a halt on our migration road map to get off VSC 6.2.1 P1D6.

As a result we have to go back to the drawing board. We plan now to build a completely new vCenter environment with VSC 7.0 and SnapCenter 4.0 and perform a VSC 6.2.1 P1D6 migration to Snap Center 4.0. 

VSC 7.0 is the only version supported to co-exist with Snap Center 4.0.

For us unfortunately, it was important to migrate from VSC 6.2.1 to Snap Center 4.0 due to the amount of SMVI snapshots we perform through VSC. VSC 7.0 no longer performs SMVI snapshots which is why we are moving or trying to move to Snap Center 4.0. Due to the incompatibility with 6.2.1 and Snap Center 4.0 we have hit a migration road bump.

Too bad NetApp can't make the migration from VSC to SnapCenter 4.0 seamless...

[DavidDAVE]

This is exactly were my problems started, as Im not being able to create snapshots with SC 4. Fortunately we tried first on a secondary vCenter enviorenment, so our production is still protected with an old VSC version + manual snapmirrors.

[COSNA2]

We are able to create Snapshots with Snap Center 4.0 just fine. We have tested it. It does the snapshot fine and mirrors/snapVaults to our backup targetss fine. Just that our VSC is un-manageable due to being incompatible. It disappears from vCenter without warning and generates log errors stating that there is a problem with the VSC plugin.

[AshishGupta]

@COSNA2, that is not true (no seamless migration from VSC/SMVI to SnapCenter)!

NetApp has released a utility called 'NetApp Import Utility for SnapCenter & VSC' exactly for this purpose.

It can be accessed on the toolchest here: https://mysupport.netapp.com/tools/info/ECMLP2840096I.html?productID=62135&pcfContentID=ECMLP2840096

Resources

YouTube video on import utility: https://youtu.be/CEQmIEzNVfA

VMware community thread highlighting actual challenges and detailed step: http://community.netapp.com/t5/VMware-Solutions-Discussions/NetApp-Import-Utility-for-SnapCenter-and-Virtual-Storage-Console/m-p/137248#M9154

Feasibility for migration

• Check IMT tool to validate if vCenter, ESXi & ONTAP versions deployed in customer’s environment are supported
• SCV 4.0 supports vCenter 6.0U3 and above, ONTAP 8.3.1 & above
• VSC 7.1 supports vCenter 6.0 and above and ONTAP 9.1 and above
• SnapCenter requires customer to be on premium bundle if they have FAS/ AFF in the system (SnapCenter Standard controller-based license is automatically provided for customers on premium bundle only and not on base pack). Alternatively, they need to purchase SnapCenter Standard capacity-based license if they are using ONTAP Cloud or ONTAP Select.  For more details, refer Installation & Setup Guide, chapter “Using SnapCenter licenses”.

Detailed instructions

• Refer SCV-VSC-Import-README.pdf bundled along with the utility (NetApp-Import-Tool.zip) available at this link: https://mysupport.netapp.com/tools/info/ECMLP2840096I.html?productID=62135&pcfContentID=ECMLP2840096 

Limitations of the tool

1. SCV supports ONTAP 8.2.2 and higher. The migration utility will import only storage connections for VSC backup jobs that were performed on ONTAP 8.2.2 or later.
2. SCV doesn’t supports 7-mode and cluster mgmt LIFs. The migration utility will not import backups/ backup jobs on ONTAP 7-Mode systems or cluster management LIFs.
3. The utility does not import on-demand backup jobs.
4. Migrated backups do not allow you to restore from secondary snapshots since SnapCenter is not aware of the secondary update triggered by VSC.

Recommendations

1. The utility does not delete VSC metadata so you can go back and import again in case things go wrong. Do not uninstall VSC until you're 100% sure all backups are running in SC.  You can instead disable the VSC service.
2. You can try the dry run option in order to gain confidence about the utility without actually importing the data.

Hope this helps!

[COSNA2]

We are aware of this...

However, this process is recommended to do once you are ready to migrate from VSC to Snap Center 4.0 which we are not yet ready.

We were trying to evaluate Snap Center 4.0 along the sides of VSC before we jumped ship in the same vCenter. We were toldat first that this would be OK after recommending to upgrade to P1D6. Turns out it only made things worse for us.

Later, I found a posting in actual NetApp documentation that VSC 6.2.X is incompatible and not supported to co-exist with Snap Center 4.0.

When brought this forward and then moreconfusion started to arise from it all.

Eventually we simply yanked Snap Center 4.0 and restored our VSC to be able to actually manage it.

At this time, we are re-evaluating our options and it seems like we will be building a new vCenter with a migration plan for VSC to Snap Center 4.0.

That way, we can at least retain our existing VSC backups while we migrate to Snap Center 4.0 in the new vCenter.

[COSNA2 · Accepted solution]

UPDATE...

We managed to come up with a solution that allows us to evaluate SnapCenter 4.x while retaining our existing VSC 6.2.1 backup procedures until we are ready to cut-over to SnapCenter 4.x.

Each day start, we do the following while we assess and evaluate SnapCenter:

• Make sure that you start with a fresh clean build of SnapCenter (reverted to a snapshot of a configured stand-alone virtual machine server) with a storage arrays already manually added
• Make sure that the SnapCenter plugin does not exist in vCenter, if it does, manually 1) remove it and then 2) uninstall the software
• Join SnapCenter Server to vCenter
• On the VSC virtual machine, we run the import tool for "backup_jobs" first followed by "backups"
• We stop the NetApp SnapManager for Virtual Infrastructure service on the VSC server instance
• We reboot the vCenter Server

We conduct our testing and evaluations of SnapCenter and SMVI once the vCenter server restarts.

Before end of day, we do the following to restore VSC production jobs:

• Remove the SnapManager plugin from vCenter using the MOB procedure
• Uninstall the SnapManager Software from vCenter
• On the VSC virtual machine, start the NetApp SnapManager for Virtual Infrastructure Service
• Reboot the vCenter Server
• Shutdown the SnapCenter Server; revert to previous snapshot

The end of day procedure restores our regular VSC so that our nightly backup jobs can run successfully.

This is our interim procedure while we assess and evaulate SnapCenter 4.x before we do the actual cut over.

Once we cut over, we also plan to upgrade the VSC 6.2.1 to 7.2.

[COSNA2]

UPDATE

We have now successfully migrated off VSC 6.2.1 and are now running VSC 7.0P1 with SnapCenter 4.1.

In the coming days and weeks we will be performing the upgrade to VSC 7.2.

We want to make sure all is well and running smoothly with the current setup we have in place before we venture further.

[S-Sahu]

When trying to create a Resource group in the NetApp SnapCenter plugin for VMware for a newly created NetApp volume I get the following error

Some entities are not SnapCenter compatible.

This does not happen on existing volumes.  Can you advise the cause and remediate?

Version info

 Snapcenter Plugin for VMwareNetapp Inc.4.2.1.5469408Snapcenter Plugin for VMware