Missing topic - VMware recommendation of creating distributed port group with ephemeral binding

[Saleh Saad]

Hello,
I think the User Guide for vSphere, Data Recovery section & Veeam bp guide are missing the requirements & considerations of:
- VMware recommendation of creating Distributed Port Group with Ephemeral Binding to be used for recovery purpose, I couldn’t find relevant topic in Veeam bp.
- Restore vCenter VM that's connected to Distributed Port Group, the only article I found is kb1913 and it does not cover the case when the vCenter VM is connected to Distributed Port Group with static binding.
- Restore VMs that are connected to Distributed port group with static binding if the vCenter server is down.

[Andreas Neufert]

Hello Saleh,

thanks for sharing this. Can you please share what the exact issue is that you see? I can then check in our code if we have added some special methods for the vCenter restore that do some automated processinf for this in the background or if there are manual steps needed.

[Origin 2000]

Hi Andreas,

if you connect to a ESXi Host rather than vCenter all vDS Portgroups which use the Static Binding (vSphere Default value) are not accessible. I cant see how software wise you can give support here because for a easy fix its to late. The Admin now have to create a vSS and new Portgroup which can be difficult if youre using a LAG/LACP and when youre short on free NICs.

Maybe it might be possible to raise a warning flag (in VeeamOne?) when Veeam backups a VCSA which is connected to a mis-configurated vDS PG.

Regards,
Joerg

[Saleh Saad]

Hi Andreas,
It's not related to our VBR code as it's a limitation from VMware itself.
In our helpcenter & bestpractices guide, we need to refer to VMware recommendation
https://kb.vmware.com/s/article/1022312

As Joerg mentioned, we can include a warning flag in Veeam ONE, if we're taking backup for a VM that's connected to distributed port group with static binding, Veeam ONE to raise flag "please make sure that you're following VMware best practices to have a pre-created distributed port group with ephemeral binding, this ephemeral port is to be used only for recover the VM, and to connect the VM vNIC back to the static binding one once you finish the VM restore"
I'm not asking you to put this warning format as it's, this is just my elaborating for the content of the warning.

Dear @Joerg
As per VMware recommendation, we can have port groups with ephemeral binding using the existing NICs.
No need to have free NICs.

[Origin 2000]

@Saleh,

for sure you can have different portgroup types on the same vDS with uplinks shared to all of them. Again.... its to late to modify anything when the disaster already occurred and you have to do it prior. Changing the network and shifting vmnics around can by very challenging when having a LACP/LAG + tagged VLAN setup.
Also its not possible to change the type of a existing portgroup.

Regards,
Joerg

[Saleh Saad]

Hi @Joerg,
No need to change the type of existing portgroup, we only need to create an ephemeral one for each static one as per VMware recommendation.

for example if I have 5 distributed port groups with static binding like:
1- DPG-VLAN10
2- DPG-VLAN20
3- DPG-VLAN30
4- DPG-VLAN40
5- DPG-VLAN50
Then, we should have other 5 distributed port groups with ephemeral binding like:
1- DPG-VLAN10-eph
2- DPG-VLAN20-eph
3- DPG-VLAN30-eph
4- DPG-VLAN40-eph
5- DPG-VLAN50-eph

Those ephemeral ones should be created before getting any vCenter outage. As the ESXI host can attach the vNIC of VM to a distributed port group with ephemeral binding, so, we'll be able to restore the vCenter VM that's connected to distributed port group with static binding via restoring it to new location, during the restore wizard, at the step of "Network" you need to specify the DPG with ephemeral binding.
The same way should be followed in case of we need to restore a normal VM that's connected to DPG with static binding in case of the vCenter is down.

[Andreas Neufert]

Hi Saleh,

this seemed to be the right preparation. But on the Veeam side the question is, if we can detect that this is missing (maybe Veeam ONE topic) and check if the vcenter is down and this preparation did not happend how we can help our customers best. Maybe there are some ways thorugh API to do some hacking and automate a DR from such a scenario or at least guide our customers in a KB with the needed steps. Again if this preparation did NOT happen before the vCenter outage.

[wishr]

Hi Guys,

Veeam ONE team here.

It sounds like an interesting idea. We'll see what can be done.

Thanks