vSphere / SRM replication not respecting priority groups

Question

I'm in the process of demoing VMware's SRM.

The install is good and I can easily run a restore for a single machine.

I'm developing a recovery script for a single application is spread across about 10 servers, a couple sql servers, a couple app servers, a client access machine among a few others.

The priority groups are defined exactly as they should be and I don't need to add any intra group definitions.

When I test my recovery plan I'm seeing priority 1 VMs fire first, priority 2 not at all, and some - about half - of the priority 3 VMs boot. It looks like things eventually move on, still using this odd ordering. What the heck is happening here? Is it related to the method SRM uses to change the IP addresses? Something in the hardware version and/or VMware Tools?

All ESXi hosts and vSphere is 5.5. I'm using vSphere replication and SRM 5.8.1.

Answer 1

Once I corrected some timeout issues I was able to determine what is happening here.

It looks like the SRM preparation steps (configure storage, configure text network, guest startup, customize ip) are all executed starting with priority 1 and going through priority 5 in groups of roughly 4 VMs at a time. These steps are treated as independent of production boot.

The SQL boxes under priority 2 are large. As a result it takes a lot longer for my group 2 boxes to even get to to the guest startup. SRM doesn't wait for that process to complete on those VMs and rolls on to the next group. It makes sense really - all the VMs shutdown and wait to be booted in the right order once the reconfiguration completes.