2011-01-04 12:23 PM
I am having some major issues creating a relationship using OSSV to my secondary storage. Here is some background and troubleshooting steps I've taken. I am out of ideas at this point and appreciate any help.
Destionation SV: FAS3160 Data OnTap 8.0.1RC3 7-Mode. I only have a 1GigE port plugged in for now - though waiting on 10GigE cards.
Source: Window 2003 R2 (which also happens to be my DFM server)
Operations Manager 22.214.171.12453
OSSV Version 3.0
I want to use OSSV. I've installed the Host Agent on the windows box and then OSSV. Configured my NDMP credentials and host monitoring password. Everything is good to go inside DFM Manager.
Host Agent Status: Detected
Host Agent Cred: Good
NDMP Status: Up
NDMP Creds: Up
I've tried a couple of ways to initiate a SnapVault:
Directly through CLI on Destination - Error message: SnapVault: destionation transfer from <source> to <dest>: cannot connect to source filer.
I've also tried through policies on DFM:
I created a dataset and put my server in it. Configured the Protection Policy and it fails with same error as above when trying to connect to source.
I've done extensive troubleshooting and I am unable to resolve this issue.
Source can ping Destination via IP / DNS
Destination can ping Source via IP / DNS
dfm host diag <destionation>
All NDMP tests passed
I am able to telnet to source and destination on port 10000 - though this is my output:
C:\> telnet <source> 10000
C:\> telnet <dest> 10000
I double checked with Network team to make sure there was no filtering for any ports - nothing.
OSSV log on source tells me the same error as above along with:
Error creating relationship to <destination>
On the destination - options snapvault.access is set to * - I've also tested with host=<source>
I've unchecked the QSM Checkbox with no change. I've also tried to check it and specify destination.
I've run the svcheckinstall.exe with "Check Succeeded" as a result.
Windows firewall is disabled.
I've also done a bunch of other things that I can't even remember now - also the obvious, restarted the server.
At this point, I am thinking it is an OSSV issue as I am able to manually execute a SnapVault from a V3160 to my new FAS3160.
Any help would be greatly appreciated.
2011-01-05 03:55 AM
Hi, welcome to the comminty
I have had this issue before and it was caused by a firewall as the source was in a DMZ. In your case I would guess that maybe the IP port 10000 is in use by another application (DFM) so you could try changing this. Another method would be to try and backup your PC with OSSV in case the issue is with the source machine.
Hope it helps
2011-01-06 04:31 AM
have you tried to initialize the relationship manually with 'snapvault start' on destination system from OSSV host? you've mentioned you had checked it from filer to filer, but from OSSV host?
Snapvault uses port 10566, please check this port with telnet. 10000 is the NDMP port, and your error is snapvault-related. In fact, without being managed by DFM, port 10000 in not used at all in OSSV-snapvault communication.
Please also take a look in snapmirror.log on destination. Does it tell anything more verbose?
2011-01-06 06:28 AM
When I do netstat -a when the OSSV service is running, I see ports 10000 and 10566 sitting there listening. As soon as I stop the service, those 2 ports go away. That being said, I am not sure that I am getting a port is already in use issue.
I've actually been able to successfully create relationships using a different OSSV host and it works like a charm.
Inside the snapmirror.log, I am not seeing much at all other than my original error of "Could not connect to host"
2011-01-20 06:54 AM
I guess I forgot to update this - I honestly do not know what happened. When I got on the phone with the technician, I went through the steps and it magically worked. Kind of like taking your car to the mechanics and the noise stops. The only thing I can think of is that our Network team found something that was being blocked and opened it up without telling me.
The only thing I can tell you is to double check firewall ports and if it's a linux machine, make sure your iptables firewall is allowing 10000 and 10566. If you are using the host agent, whatever port you use for that.
Hope this helps.
2012-08-08 05:41 AM
I am having a similar issue wherein I am not able to initialize the OSSV relationship for the servers that are in DMZ. However for the servers which are on the same lan as my storage filer, I am not having any issues.
My network team says that port 10566 and 10000 are open on the firewall. I have been successfull in doing telnet <filer ip> 10566 from the server in DMZ. I have also verified thru netstat -a on the server that port 10566 and 10000 are "listening".
I am searching for a solution/workaround and came accross this discussion. Can you please suggest what needs to be done?
2012-08-27 11:58 PM
Issue resolved. OSSV failed as the network team had opened the firewall ports for the Filer's management IP only and not the other interface IPs. Once firewall rules were correctly updated to allow for all Filer interface IPs, OSSV started working without a hitch.