Currently Test Failover + Test Cleanup feature, without having to pause or stop replication works in VR, only if using SRM on top of it.
For VR without SRM, after performing the failover, the only possible option is to stop the replication. Performing the failover consolidates the replica disks at the target datastores and prepares the vm configuration files.
Hi Ruby , thats what I understood , however my client simply refuses to purchace the super expensive SRM utility . SRM test failover is the only supported way to accomplish this without having to stop and re-seed replicas .
ANY idea where i can find documentation about how you can manually ( CLI and POWERcli ) prepare Target Datastores ( where replicas currently go )?
As you correctly stated , target replica VMFS contains the HBR files in stead of conventional virtual machine files , but certaily , just as SRM prepares the files for normal operation , there must be a manual , "upsupported " way .
I want to test this unsupported process with 490 vSphere replicas running to DR site .
1> Cut the LAN between PROD and DR , just for VLANs used by vSphere , and VR.
2> PROD is now technically not "aware" of DR , and DR thinks PROD is down .
3> Recover DR VMs in Web access . Keep them powered down , and leave vNICs disconnected
4> In my home lab tests , this leaves the DR VMs in conventional VM format , stock standard VMDKs and VMXs. No HBRCFG and BBRDISK files.
5> Our storage team now creates a "flash" copy of Fiber channel luns , using IBM SVC and essentially creates a copy of all the VMFS datastores . This take an hour.
6> After this , the "flashed luns" are presented to a new isolated set of ESXi hosts .( hosts are zoned in advance , and they only have fake networks on isolated Cisco siwtch . ( we now have VMs usable in isolated cluster , that we will use later on )
7 > Remove DR VMs from inventory without "deleting from disk "
8 > The VLANS blocked in step 1 between PROD and DR are now restored .
9 > vSphere replication devices can now " talk ".
10 > Stop replication jobs as VMs should be in recovered state .
11 > Redo vSphere replication from PROD side but use DR VMs as seeds . ( this will most likely cause MASSIVE CPU storm on ESXi hosts are checksum in done ( i saw this in tests using vim-cmd hbrsvc/vmreplica.getState vmid )
Last Step > Use the flashed luns from step 5 to mount snapshot luns in isolated cluster , add to inventory , and power up with " i moved it " parameter.
I know this is complex , but I cannot provide a better solution without SRM .
Any better ideas would be greatly appreciated , stuck between I.T. and Finance departments here !!!
The only thing I could find a super hack based on Duncan Eppings atricle that suggests there might be a way .
If you are using vSphere Replication without SRM on top of it, Test Recovery is not available. The process you could follow in case you would like to keep your primary site online:
1) Perform Recovery using the second option (Recover with latest available data). In this way you would not need to power off source VMs and your primary site will be online.
2) After recovery is complete, stop the replications (which will be in Recovered state)
3) Power off recovered VMs, unregister them from VC inventory, but keep the disk files intact.
4) Manually configure all replications using the disks that were left over as initial seeds. This will cause only changes to be synced.
To ease step 4, you could use vSphere Replication multi-vm configuration wizard. Just make sure that on the target datastore each disk that will be used as initial copy is put in the folder with VM name. Then, you could try to configure all VMs at once, performing searching for seeds and confirming to use them.
Biliana , YOU ARE THE BESSSSST !!!!
Just tested this , and have to say , nice "ouside the the PDF " thinking .
You just saved me from weeks of manaul configs .
Best of all is , once recovered , the VM is in classic format ( only vmx and vmdks etc ) , so I can flash copy this to my isolated DR cluster.
You made my day !