In the course of using Veeam Backup & Replication’s vPower capabilities, we may observe that different operations give us different options and default values. Specifically, if we are to run a virtual machine from the most recent backup for a virtual lab or Instant VM Recovery the options are different for where updates to the virtual disks are to be placed.
Let’s start with the virtual lab functionality within vPower. The virtual lab allows one or more virtual machines to be booted up from the backup file in an isolated network. This network is fenced off from the production network, and runs from the backup file as an environment to do testing, training or other actions off of the production virtual machines. While setting up the virtual lab, the wizard will ask where redo logs are to be stored. These are the virtual disk changes that are incurred while the virtual machine running from the backup file. The figure below shows this step in the virtual lab wizard:
For a virtual lab, only a datastore can be chosen for the updates to the virtual disks to increase lab performance. This option prohibits a Storage vMotion task on the machines in the virtual lab, but that is by design as the virtual lab is better suited for a test environment and not a workload that would persist on the production storage. The virtual lab I/O behavior is represented in the figure below:
The other vPower capability that was mentioned above is Instant VM Recovery. This allows the virtual machine to be powered on directly from the backup file, allowing very quick access to a failed virtual machine by booting it up directly off of the backup file and placing it on the production network. During the Instant VM Recovery wizard, there is a choice on where to redirect virtual disk changes as shown below:
While the option exists to send the virtual disk updates to a datastore in the vSphere environment, the ability to perform a Storage vMotion task on the recovered virtual machine becomes disabled. The Storage vMotion option, if licensed in vSphere, is critical as it can be a way to most quickly get the virtual machine back on the vSphere production storage.
The default option for an Instant VM Recovery will write changes to the virtual disks in the C:ProgramDataVeeamNFS{VM full name} path on the Veeam Backup & Replication Server. Veeam Backup & Replication handles the task of ensuring that the ESX host or other NFS clients see “actual”, or most current, virtual disk state including all changes.
Because of that, should any data migration event occur (whether it is simple copy, backup, replication, Storage vMotion etc.), the current VM state will be picked up. This means you do not need to worry about consolidating changes that have occurred since the VM has been booted from the backup file. The figure below captures the I/O behavior for an Instant VM Recovery within Veeam Backup & Replication:
Above all else, the ability to run the virtual machine from the backup file needs to ensure that the backup content is not changed; therefore the compressed and deduplicated backups must be kept read-only. It is for this reason that in both situations, the virtual disk updates must be redirected.
It’s pretty clear that the functionality making up vPower has had plenty of thought put into it. Have you made any specific observations about redirecting virtual machine updates with Instant VM Recovery or a virtual lab? Please share your comments below.