So I have just been through this and I have the process worked out. What you need to do is:
1. Install SnapCenter to a new server (I tested this with both SnapCenter 3.0.1 and 4.0. 4.0 is far superior in my opinion, the dashboards and reports are much improved).
2. The only critical configuration you need to do in SnapCenter is:
- Add at least one RunAs Credential
- Add your SVM(s) to the Storage section (do not try and add the cluster, add the SVMs themselves via their management LIFs)
3. From the SnapCenter Server, add a new host and select the "Host OS" as "vSphere" . This installs the SnapCenter Plug-in for VMware vSphere, which must be deployed to a Windows Server. It could be your VSC Windows Server you would already have, or to the SnapCenter Server itself which is supported, or any other server. I installed it to the VSC Windows Server for simplicity.
4. In the Host deployment you must enter details about your vCenter, including an account which has Administrator access to the entire vCenter
5. Restart the vSphere Web Client or the VCSA/vCenter
6. Login to the vSphere Web Client and confirm you have a new SnapCenter for VMware vSphere Plugin available
7. Download the "NetApp Import Utility for SnapCenter and Virtual Storage Console" from the NetApp ToolChest (contact your account manager if you dont have access)
8. Extract the Utility onto your VSC Windows Server. View the included PDF for instructions on how to use the tool (the example command syntax is especially useful as you dont need to use all of the available options)
9. Run the SCV-Import.bat and import all data into your SnapCenter
10. In the SnapCenter Plugin for vSphere in the Web Client, confirm you can see your VSC backups which have now been imported into the Policies and Resources sections
12. Uninstall VSC 6.2.1 and remove it from vCenter via the "https://<vcenter>/mob" webpage. Unregister the "com.netapp.nvpf.webclient" and "com.netapp.nvpf" extensions (in that order)
13. Deploy the VSC 7.0 or 7.1 Virtual Appliance and follow the install guide
14. Restart the vSphere Web Client or VCSA/vCenter
15. Verify the VSC 7.x Plugin is listed in vSphere, then add your storage to it
There are a couple of caveats I've found to all this:
1. VSC 6.x would use default snapshot labels which you could then use for SnapVault relationships. These labels are not retained on the backup policies that are migrated to SnapCenter. You can edit each policy and either create a new label (which means updating your Protection Policies in ONTAP) or just update the policies with the old VSC labels (VSC_JOB_HOURLY, etc). I just put back the old labels so existing SnapVault relationships would continue to work.
2. Metadata about backups created by VSC is imported in to SnapCenter. However, you can only use the SnapCenter Plugin to restore from the Primary VSC Backups (local snapshots). You can't use SnapCenter to restore from secondary locations such as Vault or Mirror destinations that were created via VSC.
3. You can restore from older VSC backups only at the VM level. You can't right-click a datastore and use the SnapCenter Plugin to restore from a VSC backup, but you can do this at the VM itself. SnapCenter backups can be restored from any level, but VSC seems to only work at the VM.
4. In 6.2.1 you would install it, add your Cluster Mgmt IP, and it would detect your SVMs, LIFs, datastores, etc. In Version 7.0 and 7.1, no matter what I try, I add my cluster and it never adds my SVMs. It also never updates the dashboard which is meant to show storage consumption, performance, volumes presented, etc, but it's always empty. Also, when I view a host or a datastore and try to view the NetApp Storage information (which VSC is meant to provide) it is always empty. If I drop back to 6.2.1 the information reappears immediately. It's not a permissions issue with the ONTAP Role from what I can tell. In reality other than applying host settings there isn't much use for the VSC anymore anyway.
That's how I got my VSC backups migrated over to SnapCenter, hopefully it helps.
No, I didn't remove the roles. The VSC will update the roles as needed.
There are 3 default role that VSC 7.1 creates in vCenter, which are:
After I was finished I just went through and deleted any leftover roles that started with "VSC". I noticed that VSC 6.2.x had created a few additional roles which I had never used, so it was safe to delete them.
You can delete all VSC roles before you register VSC 7.x with vCenter, just to be safe. That is perfectly fine as VSC will create the roles it needs. If in doubt, I would delete them all after VSC 6.x is unregistered and before you register 7.x.
I want to first thank you for the detailed writeup. I found this when I was at the point of migrating from VSC 6.2.1 to 7.1, thus steps 12-15 were immensely helpful as a sanity check. I did have a comment or two - and since it's only been 6-7 months since you posted I figure it may be relevant
In Version 7.0 and 7.1, no matter what I try, I add my cluster and it never adds my SVMs. It also never updates the dashboard which is meant to show storage consumption, performance, volumes presented, etc, but it's always empty. Also, when I view a host or a datastore and try to view the NetApp Storage information (which VSC is meant to provide) it is always empty.
So I have an interesting environment where we added a third SVM to our otherwise standard-for-years 2 SVM setup on a clustered/HA FAS system. These two SVMs both have management IPs and were previously used on VSC 6.2.1 for all purposes. This third SVM, however, doesn't have a direct management IP in the way these other 2 SVMs do.
Quick note: Environment is all NFS, with the NFS storage network not having a gateway so that it can't chatter/listen to anything that isn't purely storage. VSC is on the management network, same as old VSC.
So, for this third SVM it has a NFS IP in the way I just mentioned, but it also has two other IPs that can be used as a both a NFS mount point and I guess as management (foggy on that). This is different from the other 2 SVMs as the other 2 have no mount points outside the otherwise inaccessible storage network.
Now, keeping into account what you mentioned above, imagine my surprise when I went to look at the Summary Reports and saw a single datastore from that third SVM. Not all of the 6 or 7 that live on that SVM/aggregate, but just one. There were also no VM Summary Objects. This tells me several things and also begs some questions.
Summary Reports are only functional if you add the NFS mounting IP - ala the IP I use in vSphere if I were to manually mount a volume bypassing VSC. Thus, adding the management IP to VSC that has historically been used by 6.2 and older enables general functionality, but not reporting.
VSC attempted to auto-add the storage network IPs as the SVMs (which isn't technically false), but as previously mentioned that network isn't available outside of the storage vlan that only the cluster and hosts have access too.
Why would 1 datastore show? Well, of all the datastores on this particular SVM, the datastore that I see the report on is the only one that has Storage Efficiency disabled. Why does this matter? Who knows! It's just an outlier, further testing required. <- Yeah, not true. Turns out the datastore seen on this third SVM is the only datastore from that SVM that has been mounted onto the hosts in vSphere. Who knew!
Why would no VM Summary Reports show? Well, none of the datastores on this third SVM have any VMs on them. They are datastores for long-term storage, video feeds, etc. Any VMs that have any correlation with them have OS'es on one or both of the aforementioned two SVMs, not this third one.
In conclusion: I believe I will be able to see the Summary Reports in this view, fully and accurately, if I were to make the storage network IP mount points on the SVM accessible to VSC.
Disclaimer: All environments are drastically different and this may have absolutely no relevance to anyone else who reads this, it's just been my experience so far 🙂
Thank you again for the writeup Chris. I'm very curious if you found anything since Feburary to get these reports to show or had any findings similar to mine.