Networking problems after starting a Advanced Multi-Host Virtual Lab in Veeam Backup & Replication

Today’s Homelab session dealt with the creation of a short customer demo of the Veeam Backup & Replication functionality SureBackup. As I have already implemented several SureBackup jobs for other customers, I was confident that I could quickly finish configuring the environment. For those who have not worked with SureBackup before, Veeam provides an excellent guide in their Help Center. You can find this guide here. Unfortunately the whole thing did not work out as expected. Already at the beginning I made a crucial mistake which made the creation of the demo a nerve-wracking adventure. More on this in a moment. First of all, for those of you who have no idea how the creation of a SureBackup job works, I would like to give a short outline.

In a nutshell, the creation of a SureBackup job is divided into three steps which I would like to outline briefly.

Step 1: Add Virtual Lab

The Virtual Lab is the framework for the SureBackup job. Here you define which resources (ESXi host(s), proxy appliance and network configuration) should be used. The details of the individual steps can be found here.

Step 2: Add Application Group

The Application Group defines those VMs that provide the prerequisites for the VMs to be tested. Typically, this group includes the domain controller, a DNS server and a DHCP server. The separate steps for creating the Application Group are described here.

Step 3. Add SureBackup Job

The SureBackup job connects the two previously created components (Virtual Lab and Application Group) with the VMs to be tested. Thus you define which Virtual Lab with which Application Group should be used to test your VMs. The description of the required steps can be found here.

Steps to create a SureBackup job within the Veeam Backup & Replication Console

But after this short journey back to my small but devastating mistake. As already mentioned above, I made a decision during the first step that I would regret later. When creating the Virtual Lab you have the possibility to decide how the network configuration should be done. In summary, this is where you decide whether to run your Virtual Lab on a single host using a vSphere Standard Switch (vSS) or on one or more hosts using a vSphere Distributed Switch (vDS)

Edit Virtual Lab – Networking within the Veeam Backup & Replication Console

As all my customers who have used SureBackup so far do not have the necessary licenses for vSphere Distributed Switches, I have always chosen the variant with one host and one vSS (Advanced-single host). (In retrospect this may saved my a** in some situations).

In my Homelab I configured all hosts through a single vDS. Since I did not want an additional vSS in my environment I decided to create a Virtual Lab in the Advanced-multi host configuration for the demo. One detail I didn’t know at this point and of course found later in the help desk of Veeam is the fact that Veeam Backup & Replication has no way to configure a vDS automatically.

Veeam Backup & Replication does not offer an option to automatically configure the vDS. The vDS must be preconfigured in your virtual environment.

This means that although the Distributed Port Group(s) for the Virtual Lab is/are created on the vDS, the uplink configuration is inherited from the vDS without any adjustment. And thus the isolated network is not as isolated as the name would suggest. If you continue reading the information about Advanced Multi-Host Virtual Labs in the Help Center (here), you will also be informed that the port groups on the vDS must be isolated from the productive infrastructure and this must be done manually by the administrator.

Without this knowledge I obviously finished the creation of the Virtual Lab, created an application group with a virtual domain controller (including DNS and DHCP) and the corresponding SureBackup job with my demo web server. So far so good. Until approximately 5 minutes (to be exact until the virtual domain controller was started) after starting the SureBackup job nothing worked at all. As you can imagine, it is no fun if you suddenly have a duplicate of your productive domain controller in your lab network. For a few hours I was unable to access either the Veeam Backup & Replication Server or the vCenter Server Appliance due to temporary name resolution failure. So it took some time until I was able to stop the SureBackup job or terminate the restored VMs manually. After the duplicate of the domain controller was terminated, it didn’t take very long and everything went back to normal. So I started to track down the issue. I decided to repeat the configuration I made in Veeam step by step, verifying each step in vCenter.

So the first step is to rebuild the Virtual Lab, apply the same settings as before and then monitor the creation of the Distributed Port Group in vCenter. The creation ran without problems, therefore, we briefly check the settings point by point and then proceed to step two, the creation of the Application Group. But stop. Why does the Distributed Port Group for the isolated network have two active uplinks? Shouldn’t there actually be no uplinks in the sense of isolation?

Two active uplinks on the Distributed Port Group for the isolated network

That was the point where I became suspicious and started consulting Veeams Help Center. There, as you already know, I found the answer. I then simply set the uplinks on the Distributed Port Group to unused, repeated the remaining steps (creating the Application Group and creating the SureBackup Job) and started the SureBackup Job again. Less than 15 minutes later and the whole thing looked like I expected it to.

Result of the SureBackup Job after adjusting the uplinks of the isolated network

Wrap-Up

I took the time to check if the same problems occur when creating a Virtual Lab with Advanced-single host configuration and perhaps it is a general problem in the last update. But this was not the case. Everything worked without manual configuration of the VSS without any problems.

Once again it has been shown that it is always a good idea to test things in non-productive environments like a homelab before using them in productive environments. Even though Veeams Help Center points out the behaviour when using the Advanced-multi host configuration, I would have appreciated a note or a short warning in the Veeam Backup & Replication Console when creating the Virtual Lab.

Fortunately my Homelab is a nested lab, so neither the internet nor the various streaming services were affected by the outage. At least I was able to analyze the problem in calm and find a solution without disturbing the other members of the household (Happy wife, happy life).