I recently had a deployment that required testing of a physical server running the Veeam Windows Agent to be restored as a virtual machine. The customer was using VMware, which presented a little bit of a challenge as Veeam does not currently have an “Instant Restore to VMware” option like is available for Hyper-V. While it would be cool to test this option in Hyper-V, it would not be cool (IMHO) to be running Hyper-V in a production data center! There are still ways to restore a physical server to a virtual machine in VMware for DR purposes, even if it takes a little bit more work to get there.
The first option is to perform a restore by exporting the backed up disk contents as a virtual disk.
This option will allow you to select the backup, restore point and specific disks that you want to restore. It will also ask for a target, which for the case of VMware should be a specific vSphere host server, so that you can select a datastore as the target storage. By choosing a datastore in the Path to folder field, you will notice that the only export option is VMDK, while VHD and VHDX are greyed out.
The disk export then proceeds as expected, and creates the VMDK files associated with the backed up disks. At this point, a new VM can be created and assigned the appropriate resources. For as many disks that were restored, add a new virtual hard disk, choose to use an existing disk and point to the VMDK files that correspond to each disk.
I was told that the most of the time, this process actually works fine, but in practice with a couple of different agent backups, we got thrown into a vicious BSOD reboot cycle. That is what led us to testing the Bare Metal Recovery option from the Veeam Recovery Media.
Similar to the previous procedure, a new VM is needed for this process. The Veeam Recovery Media must also be created and the ISO file uploaded to a datastore so that the VM can boot via CD drive – datastore ISO. The VM must also have the same number of blank disks added that are at least the same size if not a little bit larger than the original disks on the physical server. Once the VM boots, select Bare Metal Recovery and go through the wizard. In this case, the backup file lives out on the network, rather than say a USB drive attached to a bare metal physical server, so you need to get the VM connected to the LAN.
One minor misstep at this point was building the blank VM with a VMXNET 3 vNIC just based out of habit. The recovery VM could not locate ethernet drivers, which was easily fixed by reverting the vNIC type back to E1000. That allowed the VM to be placed on the network to find the backup file location.
The rest of the wizard is pretty self explanatory, although again another little “gotcha” was found at selecting the Restore Mode. The initial selection of Entire Computer popped up a warning that disk mapping was not successful, which forced us to use Manual Restore (advanced), which essentially brings up a version of disk manager and allows you to position the partitions as necessary. This physical server had 2 hard disks, but 3 partitions on disk 0, including the OS partition. For whatever reason, the wizard initially tried to place the disk 0 partitions on disk 1 and didn’t have any more room for the final partition. Using the disk mapping window, we were able to remove all partitions from disk 1, place the disk 0 partitions in the proper order, and then finall place the large partition back on the now empty disk 1 where it belonged.
Once the recovery finished, we were left with a fully functional restore of the server, just in the state of a virtual machine. The process wasn’t quite as simple as a magic “Instant” restore button, but it certainly proved that Veeam agents are a great tool for protecting physical machines and being able to bring them up as VMs. While this isn’t a straight P2V, it could be very useful for DR purposes when it comes to legacy servers or other physical machines that may still be hanging around. It certainly helps bring availability to more than just virtual infrastructure.