The Veeam VAO Virtual Lab provides a safe environment where the Veeam Availability Orchestrator has the ability to run test and verify the Replicas of Production virtual machines. The Veeam VAO Virtual Lab in reality mimics the Virtual Lab already available in the Veeam Backup & Replication. So what’s the difference? When thinking about designing a virtual infrastructure to prevent failure this is where the Veeam VAO comes handy: a dedicated set of components that can test, verify, fail-over and document all the necessary steps in case of planned and unplanned disaster recovery scenarios.
And there’s more. Since it is possible to create even multiple Veeam VAO Virtual Lab configurations within the same Veeam VAO Site it is also possible to dictate which ones should be available for specific validation and fail-over jobs. This provides even more flexibility for larger environments and even the possibility to create different tiers of resources the Veeam VAO Virtual Lab will use based on different Service Level Agreements (SLA). For example a “Gold Policy” which allows a Virtual Lab to use a “tier 1” storage for fail-over scenarios and a “Silver or Bronze Policy” which runs a Virtual Lab using a “tier 2” storage maybe slower compared to previous one and with more space available. For example the latter could be used to run verification of large enterprise application with their dependencies on other services like Active Directory, SQL and Oracle databases and more.
All Veeam VAO Virtual Lab configurations are managed directly from the Veeam VAO console running in the DR Site. These are completely independent from the existing Virtual Labs created using the Veeam VBR in the Production Site. Such separation allows for a higher design resiliency in case of failures.
There are many scenarios and the Virtual Lab definitely provides the flexibility just by reusing the current hardware resources presented to the VMware vSphere environment. This can be infact any combination of Host, Network Switch and Datastore resources.
This article offers a quick glance on the main configuration steps for the Veeam VAO Virtual Lab.
Veeam VAO Virtual Lab setup
From the server where the Veeam VAO is installed there is a link to launch the embedded Veeam VBR. This is the one used to create the Veeam VAO Virtual Lab in the DR Site where the VMware virtual machine replicas are tested and verified.
Next is associate a VMware vSphere Host where the Veeam VAO Virtual Lab will run. This will create in turn a VMware Resource Folder and a Virtual Appliance inside this folder with the same name. This step is configurable by changing to the desired name. It is a very important step as this resource folder provides the isolated bubble where the VM Replicas can consume the resources. More on this later.
Next is to specify the Datastore where the temporary changes (captured by VMware redo log files) will sit. By default this is using the same Datastore location where the Virtual Lab is sitting. Should a “faster” VMware Datastore be available it is possible to use this one instead and redirect the location where the redo log file is created. For example this could be used to target different types of storage based on different SLAs. This space by the way shouldn’t be massive for two reasons:
- the redo log file consists only of changes from base file. Not everything. So even a 1 TB virtual machine can show only a few hundreds of MBs when booting, initialize some services/daemons and run the verification tests.
- all changes will be automatically discarded at the completion of verification jobs
- for application groups left running even after the validation completes they have a really small footprint.
In the Proxy section it is where the actual Virtual Lab VM is configured. And namely this is for the VM appliance name, it’s network configuration (static IP address recommended) and the ability to configure the Virtual Lab as an HTTP / HTTPS Web Proxy for the VMs in the bubble, should these need internet access.
The Isolated Networks section allows to create (duplicate) the Production networks inside the bubble. This includes for example the option to specify VLANs as well.
For each one of the duplicated networks the Veeam VAO Virtual Lab creates a masquerade IP Address. This way the VMs in the bubble can still use their own original IP addresses without conflicting with the current Production network. In fact these isolated VMs cannot communicate with the outside world by default.
Should these isolated VMs be accessible from the Production environment it is possible to create static mappings from the Production network.
And finally a main view of the main settings to review before amending changes. These can be edited at any time.
The wizard has now all the necessary info to proceed with the Veeam VAO Virtual Lab setup.
As soon as it is created it will appear on the associated vSphere Host as a Resource Folder and the virtual appliance inside. Although this is using very little resources itself it is possible to configure the resources on the folder level like a traditional vCenter Resources Folder. All the verified VM Replicas will consume resources from this “folder”.
Now that a Virtual Lab has been created it is a matter to choose which Site will use this one.
By selecting the pertinent Site is possible to associate the desired Veeam VAO Virtual Lab.