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:
WARN SnapManagerWeb PID= TID= Host X.X.X.X not found in nsm
ERROR SnapManagerWeb PID= TID= 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
ERROR SnapManagerWeb PID= TID= 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.
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= TID= Failed to find host (X.X.X.X). Please check the host is up and running or check thefirewall 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"
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.
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...
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”.
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.
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.
The utility does not import on-demand backup jobs.
Migrated backups do not allow you to restore from secondary snapshots since SnapCenter is not aware of the secondary update triggered by VSC.
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.
You can try the dry run option in order to gain confidence about the utility without actually importing the data.
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.
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.
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.