2011-07-06 01:27 PM
Being an N-Series customer means that getting help on the NetApp software products is not easy. Our IBM support channel is not sufficiently skilled with the software to be of a lot of assistance and the escalation path into NetApp Engineering is simply too slow to be useful, hence my reliance on Community support for these products. Hopefully NetApp engineers can provide sufficient unofficial support through the forums to enable us to use the rebranded products effectively.
We made a design decision when building our N-Series deployments that we would keep all Server<->Filer and Filer<->Filer traffic private. We have a seperate vlan for VMware ESX to use for NFS, another for the MS-SQL cluster to use for iSCSI, another for replication between sites etc. These networks are numbered in 10.0.0.0/8 and hence always seem to be found before the public network of 184.108.40.206/16. The private networks are exactly that, private ( not routed ) so any attempts by software running on servers outside of this environment e.g. vCentre can not communicate with the filers using them.
The designers of SMVI and SVC seemed to have made assumption about network topology, i.e. that all the FIler interfaces would be public and that is still causing us issues. It completely stoppped SVC2.0.1 from working and would still seem to be an issue in 2.1, it prevents the standalone SMVI from initiating snapmirror.
Perhaps the solution is to dumb down the discovery parts of these products and let us manually configure or over-ride IP settings.
2011-07-06 01:36 PM
I have tried Keith's suggestions and have the same result. In the Monitoring and Host Configuration Panel, It make no difference whether I add a controller using is DNS name ( which resolves the the public IP address ) or the public IP address itself. SVC goes and queries the controller and identifies it correctly but deletes any exisiting controllers leaving me with just the one I added. If I select 'Update' the other filer is re-discovered as 'unknown' and is shown in the table as -unknown- (10.93.104.11) i.e. it is being found by looking at the NFS mounts on the ESX hosts. Eric had suggested that 2.1 was going to fix the issues associated with private networks. It would seem that is not the case.
Hmmm, after more poking around, I have managed to use the 'Modify Credentials' command to update and get the correct management IP to stick. An update no longer causes the filers to dissappear or be rediscovered, so progress I think.
2011-07-06 02:15 PM
Well, I seem to be making reasonable progress, configuring backups and running them from within vCentre seems to work as it is supposed to.
The notification email is going to need fixing
Backup backup_Test - DS_20110707085546 completed with status SUCCESS.
You can view the log entries at https://[fe80:0:0:0:0:100:7f:fffe%11]:8043/smvi/logViewer?id=backup_Test - DS_20110707085546.
This vCenter server is 2k8R2 and has IPv6 configured. Building a URL with an IPv6 link local address is not particularly useful
2011-07-07 07:36 AM
I'm glad to hear progress is being made. It soundlike the SMVI engine can talk to the controllers fine, have you tried adding the controllers to the Provisioning and Cloning section? I suspect that will work fine as well. I have asked one of the VSC developers to look at this thread to see if he can give us some suggestions on the "update" problem and "add controller" problem.
Thanks for the updates.
2011-09-01 04:24 AM
I have a similiar Problem with the URL in the notification Email. In my Case its a IP in the URL that I can't reache from the PC, where I become the notification Email.
Do you have a solution for Customizing the URL in the notification Email?