SureBackup to different vCenter -> NIC mapping not found

[mdiver]

In a customer project we face the issue to run SureBackup into an independent vCenter.
The names of the (d)vSwitches are the same. But obviously the internal IDs differ. So, VBR does not find the correct target vSwitch to map into. We get a warning with the mapping error and only heartbeat works.

The used to be an idea for something similar with NSX-T:
vmware-vsphere-f24/surebackup-and-nsx-t ... 81255.html

But it seemed not to have worked as expected, as application scripts are skipped, when the initial mapping fails.

Is there a more recent workaround for that issue?

Thanks
Mike

[PetrM]

Hello,

Looks like it's a technical issue which must be researched by our support team. Please share a support case ID with us so that we can keep an eye on it.

Thanks!

[mdiver]

Thanks, Petr.
Support-Case #07519794
Regards, Mike

[mdiver]

Veeam support says, it might be related to the UID of the vSwitches.
That was my idea in the first place.

Then it would not be possible to find a solution with two independent vCenters, as we cannot change those IDs in a supported way.
Maybe someone could agree here, so we can stop further investigation.

Thanks,
Mike

[Egor Yakovlev]

QA has a strong opinion that Standard<>Standard switches should work just fine, whereas combinations behavior of Standard, DVS and NSX are harder to predict and need to be validated case-by-case depending on setup.

[mdiver]

Thanks, Egor.
What you are saying is: for Standard<>Standard it's just the name that has to match?
Cause we are getting an error about that roughly says an ID was not found and it is standard switches.

[Egor Yakovlev]

Correct: Std<>Std between two independent vCenters with matching network components names should work.

[mdiver]

Just to follow up: Problem was solved with help of Veeam support once promoted to the next support level.
Customer had chosen the networks to be tested from the target vCenter while initially setting up the virtual lab.
Correct way is, to choose from the source vCenter here.
Here, the UID of the vSwitch seems to be crucial.
VBR wants to map the VM and does not recognize the network using the target UIDs.
Again, thanks Egor, for helping here.