I was delivering a Site Recovery Manager Jumpstart today. During the configuration of the Storage Replication Adapter(SRA) the task got stuck at 23%. I’ve seen the configuration of the SRA get stuck once before at 23% so I knew it was the “DiscoverLuns” command that failed for one reason or the other.
We ran the configuration of the SRA again and it stopped after exactly five minutes. We decided to run the DiscoverLuns task again but this time manual with use of command.pl and a xml file as input. If you read the previous article on DiscoverLuns you know how to feed command.pl with the xml file and what info the file should contain.
Running the DiscoverLuns manually worked great, but it actually took little over 15 minutes to complete before the complete results were returned by the EMC DMX3. During the configuration via the GUI the task failed after exactly 5 minutes, so it seemed to time-out. Opening up vmware-dr.xml, which can be found in the Site Recovery Manager installation folder, revealed a time out of 300 seconds:
<CommandTimeout>300</CommandTimeout>
We changed the value to 1800, restarted the SRM service and reconfigured the SRA successful.
Duncan – thanks for the post!
Here’s the scoop – one of the SRM API calls “discover LUNs” asks the array to report back “all the LUNs that are being replicated”.
On mid-range arrays, this list is usually pretty short, but on large Symmetrix arrays, it can be a long list.
Good news – we’re working on our next SRA (to ship pretty soon) to leverage the fact that we know which hosts are ESX hosts to filter the list.
We expect his to speed up the DiscoverLUNs call and reponse dramatically….
For those of you reading – this is now officially fixed in the latest SRA (which also adds TimeFinder/Snap support for the recovery site) – covered in Duncan’s post here:
http://www.yellow-bricks.com/2009/04/27/srm-three-updates-emc-lsi-hitachi-sra/
We’re committed to always having the broadest, 100% complete and excellent VMware SRM support and integration.