I have a weird issue, we have replication on our Fibre Channel LUN's and it replicates from SAN A (source) to SAN B (destination) all ok and VMware see's the LUN. We decide to try a test manual failover on the weekend as this is our production servers and need to carry out the tests.
I carried out a manual failover as follows,
SAN A:
1. I stop the replication task
2. Change volume to destination
SAN B
1. Change the volume to source (confirm VMware sees the volume ok)
2. Restart the reverse replication Task.
When I go to restart the reverse replication on SAN B it says the task cannot be started as the remote ip address is not set. So I deleted the replication task on SAN A and tried to create a new one on SAB B and got the following message "Volume replication tasks can not be created because there is no remote node connected." However in the Host Bindings it says Remote node Host name: dss26427663 IP address: 10.100.2.233 Status: Reachable.
Yes they are on the same ip network and no vlan, they can also ping each other. If i create new volumes on SANS and use A as the source and B as destination I can create a replication task just not the other way around
I tested it on my servers here in the lab and works for me, is there some events that took place that you post? Is this a production server or test server, if test server I could take a look over a Netviewer session.
The servers are in production, but only server A serves out volumes at the moment. Ok so i went on to SAB B and disconnected the Host binding and it removed all the replication tasks on both servers. I then setup the remote ip address and it connected ok. I can now create replication tasks both ways, maybe the password or something became corrupt, not sure but seems ok now. Will know for sure once all the replication is in sync and i try again
It seems to be working ok now , i have carried a manual failover on a test vm and volume and seems to work correctly and allows the reverse sync to work as well. Must the admin password be the same on both DSS servers for the GUI, as I am not sure what could of caused the problem, we did have some power issues here a couple of weeks ago so maybe something happened then.