SRM Test Would Use the Recovery Port Group, Not the Isolated Network

Before a recovery plan test, someone notices that the plan's test network shows a real disaster recovery (DR) port group rather than an isolated test network. The site's network mapping says Isolated network (auto created) for tests, so how can the plan point somewhere else?

The plan has its own setting. Broadcom documents this exact case in KB 375276:

• The affected recovery plans had their Test Network configured with DR port groups instead of Use site-level mapping.
• So the test mapped the VMs to the named recovery network, not to an isolated test network.

This article shows how to find which setting a test would actually use, using fictional port groups. It covers reading the configuration only. It does not start a test, run a recovery, clean up or reprotect.

This guide is based on source research only. Nothing in it was run.

Two places decide the test network

In SRM 8.8, the Test Network page appears when you create a recovery plan. Broadcom states: "If there are no site-level mappings, the default option Use site-level mapping creates an isolated test network" (Create a Recovery Plan, SRM 8.8).

The key point: a plan that names a network does not inherit the site's test choice. Setting the site mapping to isolated does not change a plan that names a DR port group.

What about per-VM network overrides?

The Live Site Recovery 9.0 guide lets you change the network mapping for an individual VM in an array-based, Virtual Volumes or vSphere Replication protection group without removing protection, using Override site mappings (Configure Inventory Mappings for an Individual Virtual Machine, 9.0). That page describes the recovery mapping for one VM. It does not say how a per-VM override interacts with the plan's test network, so this guide makes no claim about that. If a VM in the plan has an override, record it and treat its test placement as unconfirmed.

Before you start

• Read-only access to Site Recovery in the vSphere Client at the recovery site. Every step below only views settings.
• The owner's retained configuration evidence, if the client view does not show a value: for example a change record, configuration export or screenshot that names the site pair, the plan, the SRM or Live Recovery version, and when it was observed (with time zone).
• Your SRM or Live Recovery version, recorded. The KBs cover SRM 8.x and Live Recovery 9.x. The recovery plan wording below is from the 8.8 guide, and other releases may label screens differently.
• The network design for the recovery site, from its owner: which VLANs and port groups are meant for tests, and which carry production or DR traffic.

Step 1: record the site-level mappings

Follow the path in KB 398859:

1. In the vSphere Client, click Site Recovery > Open Site Recovery.
2. Select the site pair and click View Details.
3. On the Site Pair tab, expand Configure and open the network mappings.

For each protected-site network, record:

• the recovery-site network it maps to;
• the test network shown for it: Isolated network (auto created) or a named network.

Do not click New or Change. The cited sources show the Test networks choice inside the mapping wizard; they do not document a read-only view of an existing mapping's test network. If the mapping list in your client does not show it, take the value from the owner's retained configuration evidence and record its source and observation time. If neither gives the value, record the site test network as unknown. An unknown value stops the placement conclusion in Step 3 for that network.

Step 2: record the plan's Test Network choice

Open the Recovery Plans tab of the same site pair and select the plan. For each recovery network the plan uses, record what the plan shows for its test network:

• Use site-level mapping; or
• a named network.

This guide does not give a click path for viewing a plan's existing test network settings. The 8.8 pages cited describe the setting when a plan is created, not where it appears afterwards. Record what your client shows without opening an edit dialog. If it does not show the value, use the owner's retained configuration evidence for this plan (with version and observation time). If neither gives the value, record it as unknown: Step 3 then cannot give an effective test network for that plan.

Also record every VM in the plan that has a per-VM network mapping override, with its vNICs and the mapping evidence. If you cannot establish whether overrides exist, record that as unknown too.

Step 3: work out the effective test network

For each network the plan's VMs use, and only for VMs with no per-VM override and no unknown override state:

In the last row, the plan supplies the effective choice. Changing the site mapping does not help.

Two exceptions stop the table:

• A value is unknown (Steps 1 and 2). The effective test network for that network is unconfirmed.
• A VM has a per-VM override, or its override state is unknown. That VM's test placement is unconfirmed, even when the network-level row is known. Record the VM and vNIC separately; do not assign it the table's result.

Step 4: check where a named test network reaches

If Step 3 ends on a named network, find out what that network is connected to before any test runs. Use the evidence you already have:

• the recovery site's network design or VLAN register;
• the port group's VLAN setting as recorded in your inventory documentation;
• the network team's statement of what that VLAN can route to.

The question is whether VMs on that network could reach production systems or the protected site. Broadcom's guidance for tests across several hosts is to use test VLANs that provide "no route back to the protected site", or DVS switches on an isolated private VLAN, named so they are clearly for testing (Performing Test Recovery of Virtual Machines Across Multiple Hosts, SRM 8.8).

If you cannot show from evidence that the named network is isolated, treat it as not isolated, and do not test against it.

Worked example (fictional)

The record for plan RP-FINANCE. All four values come from the client view, taken on Tuesday at 10:15 AEDT on the owner's recorded SRM version. The owner's protection group record shows no per-VM network overrides for any VM in the plan, so the network-level table applies to every VM:

Effective test networks:

• PG-FIN-DB VMs: an auto-created isolated network.
• PG-FIN-APP VMs: PG-FIN-APP-DR, the real DR port group. The plan supplies this choice, so the site's isolated setting has no effect on these VMs.

The network register shows that PG-FIN-APP-DR is a routed VLAN at the recovery site. A test would therefore place recovered copies of the application VMs on a routed DR network. That is exactly the risk an isolated test network exists to avoid.

What to hand on: KB 375276's resolution is to set the plan's Test Network to Use site-level mapping, with the site test network set to Isolated network (auto created). That is a configuration change to the plan, so it goes to the plan owner as a separate change with this record attached. Re-check the record after the change and before any test is scheduled.

"The test VMs cannot reach the gateway"

This symptom does not tell you whether the test was isolated. An isolated test network exists to keep test traffic off the recovery site's production network (KB 398859), so an isolated design can produce it. A fault can produce it too, and so can a test that is not isolated at all. Two documented behaviours are relevant:

• VMs on different hosts cannot reach each other. In 8.8, when the plan uses Use site-level mapping and there are no site-level mappings, VMs recovered across hosts are each placed in their own test network. Broadcom says each test switch is isolated between hosts, so VMs in the same plan are isolated from each other. If the test needs them to talk, Broadcom's answer is a DVS or test VLAN that spans the recovery hosts but connects to no production network. It is not a production port group.
• No gateway answers. This is consistent with some isolated designs, but it is not evidence that isolation worked. In the KB 444382 incident below, test VMs could not ping the gateway or the recovered domain controller, and production DNS records were still changed. Other traffic can leave a network that does not answer ping. Isolation is judged only from the recorded topology: the effective test networks (Step 3), the per-VM mapping record, and evidence of what each named network can route to (Step 4). Where that evidence is missing, isolation stays unconfirmed. A missing gateway is also not a reason to reconnect the test VMs to a production or DR port group.

KB 444382 describes one incident in which test VMs could not ping the recovered domain controller or the gateway, while production DNS PTR records were updated by test VMs and switches reported duplicate MAC addresses. A failed gateway ping and a production impact occurred in the same test, so a failed ping cannot pass an isolation check. Broadcom notes the problem "frequently occurs when using 'User Defined' network mappings instead of auto-generated 'Isolated' networks."

The KB's resolution steps belong to that incident: removing domain controllers from the plan, matching VLAN tagging to production, and rebooting the recovered domain controller. They are not general instructions, and this guide does not recommend them. For domain controllers recovered from copies, see Domain controllers and VMware snapshots, clones and restores. For address conflicts, see Duplicate IP or MAC after a VM clone or restore.

Troubleshooting

Acceptance checks

1. Steps 1 and 2: the site mappings and the plan's Test Network choice are recorded for every network the plan uses.
2. Step 3: each network has an effective test network written down, with the object that supplies it (plan or site), or is marked unconfirmed because a value is unknown.
3. Every VM with a per-VM override, or with unknown override state, is listed with its vNICs and marked placement unconfirmed.
4. Step 4: every named test network has evidence of what it can reach. A network with no such evidence is marked "not shown to be isolated".
5. Nothing in the record uses a failed gateway or peer ping as evidence of isolation. A record with a failed ping and any production impact (for example DNS changes) is not accepted as isolated.
6. Any unconfirmed item means the record is not test-ready. This guide does not decide test readiness on its own.
7. Any change to the plan or mappings goes to the plan owner as a separate change. The record is checked again after the change and before a test is scheduled.

Risk notes

• A test on a routed network is not a harmless test. KB 444382 shows that recovered copies can change production records when isolation fails.
• Changing a plan's Test Network is a configuration change. Record the current values first, so the owner can see what changed.
• Changing the site mapping affects every plan that uses Use site-level mapping, not just the one under review.
• Do not edit to inspect. Opening an edit dialog risks saving a change by accident. Use views and your own records.

These are source-documented behaviours. Expert review and a lab check against your own recovery design are still needed before any change.

Learning notes

• A recovery plan that names a test network uses that network, whatever the site mapping says.
• Use site-level mapping is what makes a plan follow the site's isolated choice.
• Isolated network (auto created) is the default site test network, meant to keep tests off production.
• An unreachable gateway is consistent with isolation, but also with faults and with a test that leaks into production. It never proves isolation.
• KB 444382 is an incident record, not a procedure.

References

Related articles

• Implement VMware-to-Azure disaster recovery
• Duplicate IP or MAC after a VM clone or restore
• Domain controllers and VMware snapshots, clones and restores