So this weekend, I was doing SRM upgrade for a customer from an older unsupported version to the latest version. The whole process was quite lengthy and complicated as they were moving from windows based Site Recovery Manager to an Appliance and had a large number of recovery plans which they had.
Adding to the complexity was the SRA based replication that they had configured. Now we did all the pre-reqs, testing, validation etc. and finalized below basic plan.
- Upgrade the SRA
- Do an in place upgrade of SRM to 8.2
- Migrate the SRM from Windows to Appliance
- Do another upgrade to 8.5
I followed the plan to the T and didn’t face any issue during the upgrade and the testing went swimmingly…….LIKE A STONE.
None of the recovery plan wanted to work, whenever I tried running the plan, it kept complaining about invalid datastore on the recovery site. Now, for the ones who might be unfamiliar with the Test Recovery steps with SRA, here are the steps in brief:
- Sync Storage – Sync the changes between site before the failover.
- Restore Recovery site hosts from standby
- Suspend non-critical VM’s at protected site.
- Create writable storage snapshots – Change the storage snapmirror to Read-Write mode, mount the datastore on the target hosts and register the Recovery VM’s
- Configure test network. – Create a isolated test network at recovery site and attach the VM’s to this network.
- Power On the VM’s based on priority
Step 4 was where I was getting the error –
Some Virtual Machines in the protection group could not be recovered. Invalid Datastore [snap-xxxxx-<Datastore Name>]After scratching my head for a while and looking at all sorts of logs, I tried validating the datastore name at protection and recovery site, now why did I take so long to look at something so basic, well the customer was using a really long name (~78 character) for the datastores and in first glance the names were similar.
When I looked closely, sure enough the datastore name was getting truncated which made me think that there might be a character limit on the datastore names, so I referred the VMware official document for naming the datastore here.
The document says that the limit is 42 character but the customer was already using more than 42 characters and everything was working as expected. So I did some more digging and found an article here, which mentioned the limit to be 80.
So I truncated the name of the datastore by a few characters (~read around 20) and lo and behold everything was working again.
Seems the newer version Site Recovery Manager has some added checks and balances when it comes to datastore validation when registering the VM’s as earlier version didn’t seem to care about the mismatch in names in Protected and Recovery Site.
P.S. -> Another way I could get around the issue was to remove the snap-xxxxx prefix from the datastore that Site Recovery Manager adds to the Recovery Site datastores to avoid naming conflicts.
The prefix is controlled by an advanced setting storageProvider.fixRecoveredDatastoreNames in the storageProvider section. Setting the value for this property to true will remove the snap-xxxx prefix from the datastore name, which would let you use a few more precious characters while naming the datastores.
AllTechInCloud 