There are two VMware sites, Prod and DR, both got its own vCenter and network infrastructure. VBR and VRO are installed on DR site (vCenter). Both vCenter are configured in VBR, data flow will be with backup proxies on prod vCenter to repo server on DR site. I built recovery plans with network (port) translation done by recovery location(s), That is working fine. There is a vLAB (runing on DR-Host) with Networks definied on DR site, also working fine. So I tried to work with Lab Groups in VLab to get some DC and DNS VM runing as a base infrastructure but it failed, as the “prod networks” are missing on the DR-Host where the vLAB is runing. I’ve already defined that network port group in the vLAB config on VBR (and resynced with VRO). Anyone using Lab groups? BTW. it is V12.3 not V13 yet.
Using Lab Groups in vLabs for VRO
Best answer by AlecKing
Hi Martin, is the Datalab in VRO associated with the Recovery Location? This allows the lab to ‘inherit’ the network mappings (and some other settings) from the location.
It’s here in the User Guide (if you are still on previous version 7, then it’s here)
+1Hi Martin,
Alas, network mapping in VRO + VBR virtual labs is complex (I am still working on simplifying it!).
VRO often has to merge two sets of network mappings -
- You have prod networks e.g VMNET-PROD1 and you map this in VRO recovery location to VMNET-DR1. That will be used when you actual run your plan in production recovery.
- You have virtual lab networks and you map them in the lab config, e.g. VMNET-DR1 to VMNET-DR1-LAB
This will work for testing in VRO, because VRO recognises the ‘implicit’ mapping where “VMNET-PROD1 should land on VMNET-DR1 (from VRO recovery location mappings); but this is a test and VMNET-DR1 is mapped to VMNET-DR1-LAB (from the virtual lab mappings).”
End result - VMs from Prod1 land on DR1-Lab network for a test.
This will break if you try to add lab groups, and those lab group VMs are on, for example, VMNET-PROD2.
If there is no such network in DR; and no relevant mapping in VRO recovery location; then VRO will not know where to map the networks for these lab group VMs.
Assuming it’s OK that your lab group VMs land on the same test network as your plan VMs, then you should add another mapping to the VRO recovery location, for the lab group VMs.
Map them to the ‘live’ network in DR (in my example, add mapping to VRO recovery location for VMNET-PROD2 to VMNET-DR1)
When VRO interprets these mappings, it will make the implicit connection that VMs that have ‘production restore’ mapping to VMNET-DR1 should all be tested in VMNET-DR1-LAB.
Hope that helps!
Thanks for the quick answer. Which mapping will be interpreted where?
There is the mapping configured into vLAB in VRO.
DR-A=>vLAB_DR-A
In VRO Recovery Location remapping
PROD-A=>DR-A
In Lab Group there are VMs all on PROD-A
In Recovery plan there are all VMs on PROD-A
When testing without Lab Groups all is running fine. VMs will be remapped from PROD-A to DR-A then DR-A will be found on vLAB and “renamed” to vLAB_DR-A and connected to vLab appliance.
But when using Lab groups, the recovery location remapping or in vLAB in VRO had not effect for the VMs in Lab group. vLAB ends with “You are about to restore to the same location where the DataLab resides. Restored VMs will be connected to the same networks as the source VMs.
Some of the source networks specified for this VM are unavailable on the host DR-HOST” (there is the vLAB running). btw we are using vDS.
+1Hi Martin, is the Datalab in VRO associated with the Recovery Location? This allows the lab to ‘inherit’ the network mappings (and some other settings) from the location.
It’s here in the User Guide (if you are still on previous version 7, then it’s here)
Hi Alec,
that was my fault, vLAB was in the scope, but not associated with the recovery Location. Thank you for your time.
Martin
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.