Migrate Virtual Machines between different Hypervisors by using Veeam Backup and Replication Instant VM Recovery
In order to migrate virtual machines between different hypervisor environments, we can use Instant VM Recovery by Veeam Backup and Replication as shown in this post.
With Instant Recovery to VMware vSphere, you can immediately recover different workloads (VMs, EC2 instances, physical servers and so on) as VMware vSphere VMs.
Instant Recovery to VMware vSphere can be helpful, for example, if you want to migrate your infrastructure from one environment to another, or you want to recover your infrastructure in a matter of minutes but with limited performance.
Source: https://helpcenter.veeam.com/docs/backup/vsphere/instant_recovery.html?ver=120
The same vice versa, with Instant Recovery to Microsoft Hyper-V, you can immediately recover different workloads (VMs, EC2 instances, physical servers and so on) as Microsoft Hyper-V VMs.
Source: https://helpcenter.veeam.com/docs/backup/vsphere/instant_recovery_to_hv.html?ver=120
Introduction
With Instant Recovery to VMware vSphere, you can immediately recover different workloads (VMs, EC2 instances, physical servers and so on) as VMware vSphere VMs.
Instant Recovery to VMware vSphere can be helpful, for example, if you want to migrate your infrastructure from one environment to another, or you want to recover your infrastructure in a matter of minutes but with limited performance.
During recovery, Veeam Backup & Replication runs workloads directly from compressed and deduplicated backup files. This helps improve recovery time objectives (RTO), minimize disruption and downtime of production workloads. The workloads are recovered in a matter of minutes.
Recovery Time Objective (RTO) is the maximum acceptable amount of time for restoring a network or application and regaining access to data after an unplanned disruption. Loss of revenue and the extent to which a disrupted process impacts business continuity can both have an impact on RTO.
Source: https://www.f5.com/glossary/recovery-time-objective-rto
When you perform Instant Recovery, Veeam Backup & Replication mounts workload images to a host directly from backups stored on backup repositories. This means that Veeam Backup & Replication creates fully functioning “temporary spares” with limited I/O performance. To provide full I/O performance, you must migrate these “temporary spares” to the production site. For more information, see Migration of Recovered VMs to Production Site.
Besides disaster recovery matters, Instant Recovery can also be used for testing purposes. Instead of extracting workload images to production storage to perform regular disaster recovery (DR) testing, you can run a workload directly from a backup file, boot it and make sure the guest OS and applications are functioning properly. For more information, see Finalizing Instant Recovery to VMware vSphere.
Instant Recovery supports bulk processing so you can immediately recover multiple workloads at once. If you perform Instant Recovery for several workloads, Veeam Backup & Replication uses the resource scheduling mechanism to allocate and use optimal resources required for Instant Recovery. For details, see Resource Scheduling.
Source: https://helpcenter.veeam.com/docs/backup/vsphere/instant_recovery.html?ver=120
How Instant Recovery Works
When Instant Recovery is performed, Veeam Backup & Replication uses the Veeam vPower technology to mount a workload image to an ESXi host directly from a compressed and deduplicated backup file. Since there is no need to extract the workload from the backup file and copy it to production storage, you can perform recovery from any restore point in a matter of minutes.
The image of the workload remains in read-only state to avoid unexpected modifications. By default, all changes to virtual disks that take place while a recovered VM is running are logged to auxiliary redo log files residing on the NFS server (backup server or backup repository). These changes are discarded as soon as the recovered VM is removed, or merged if you migrate the VM to the production site.
To improve I/O performance for a recovered VM, you can redirect VM changes to a specific datastore that is closer to the host where the VM resides. In this case, Veeam Backup & Replication will trigger a snapshot and will put it to the Veeam IR directory on the selected datastore, together with metadata files holding changes to the VM image.
Source: https://helpcenter.veeam.com/docs/backup/vsphere/instant_recovery.html?ver=120
Migration of Recovered VMs to Production Site
To migrate the recovered VMs to the production storage, you can use one of the following relocation methods:
- Use Storage vMotion to quickly migrate the recovered VM to the production storage without any downtime. In this case, original VM data will be pulled from the NFS datastore to the production storage and consolidated with VM changes while the VM is still running. Storage vMotion, however, can only be used if you select to keep VM changes on the NFS datastore without redirecting them. Note that to use Storage vMotion, you need an appropriate VMware license.
- Use Quick Migration. In this case, Veeam Backup & Replication will perform a two-stage migration procedure — instead of pulling data from the vPower NFS datastore, it will recover the VM from the backup file on the production server, then move all changes and consolidate them with the VM data.
Source: https://helpcenter.veeam.com/docs/backup/vsphere/instant_recovery.html?ver=120
Veeam vPower NFS Service
The vPower technology enables the following features:
- SureBackup
- SureReplica
- Instant Recovery
- Instant Disk Recovery
- Staged restore
- Universal Application-Item Recovery (U-AIR)
- Multi-OS guest OS file restore
The key construct of the vPower technology is the vPower NFS Service. The vPower NFS Service is a Microsoft Windows service that runs on a Microsoft Windows machine and enables this machine to act as an NFS server.
On the vPower NFS server, Veeam Backup & Replication creates a special directory — the vPower NFS datastore. When you start a VM or a VM disk from a backup, Veeam Backup & Replication “publishes” VMDK files of the VM from the backup on the vPower NFS datastore. Technically, Veeam Backup & Replication emulates the presence of VMDK files on the vPower NFS datastore — the VMDK files themselves are still located in the backup file in the backup repository.
The vPower NFS datastore is then mounted to the ESXi host. As a result, the ESXi host can “see” backed-up VM images with the help of the vPower NFS datastore and work with them as with regular VMDK files. The emulated VMDK files function as pointers to the real VMDK files in the backup repository.
The vPower NFS datastore stays mounted to the ESXi host. Each time you start an operation from the list, Veeam Backup & Replication checks whether vPower NFS datastore is mounted to the host. If you manually unmounted the datastore or the datastore was unmounted by other causes, Veeam Backup & Replication remounts the datastore.
Veeam vPower NFS datastores are service datastores that can be used for vPower operations only. You cannot use them as regular VMware vSphere datastores — for example, you cannot place files of replicated VMs on such datastores.
Source: https://helpcenter.veeam.com/docs/backup/vsphere/vpower_nfs_service.html?ver=120
Performing Instant Recovery from Hyper-V to VMware vSphere
In order to migrate a Microsoft Hyper-V virtual machine to vSphere, we can use the backups of the Microsoft Hyper-V virtual machines created with Veeam Backup & Replication as shown below. We can also do the same vice versa by using backups from vSphere to migrate the virtual machines to Microsoft Hyper-V.
Select under Home -> Backups -> Disk the latest backup, right click on it and select Instant recovery -> VMware vSphere …
In the opening wizard first select the latest restore point you want to use to create the virtual machine from in the vSphere enviromment
Choose an ESXi server to run the recovered virtual machine on.
Choose the VM folder, resource pool and target network in the vSphere environment for the recovered virtual machine.
Finally click on Next.
Below I will enable Redirect write cache and select a datastore from the Default policy.
Before it is started, the VM is snapshotted to redirect all written data to a separate disk file. Once booted, the guest will read existing blocks from the backup storage and write/re-read new blocks on the configured storage, whether being a datastore or a temporary file on the Veeam Mount Server local drive (Typically in C:\ProgramData\Veeam\Backup\IRCache\ but any disk may be used depending on the available free space).
To ensure consistent performance during the Instant VM Recovery (IVMR) process, it is recommended to redirect writes on the same datastore where the instant-restored VMs will eventually be moved. This will not only improve the performance of the restored VM but it will also reduce the network traffic going through the Veeam Mount Server.
Source: https://bp.veeam.com/vbr/Support/S_Vmware/instant_vm_recovery.html
Optional we can provide a reason for performing this restore operation or in my case a migration operation.
Finally we can trigger the instant recovery to VMware vSphere.
The restore is now in status Waiting for user to start migration as shown in the figure above. We now have to perform a Quick Migration as shown below in the next section which will migrate finally the VMDK files from the Veeam backup server and its own NFS datastore to the production datastore in our vSphere environment.
Below you can see that the virtual machine so far is using this NFS datastore from the Veeam backup server.
Perform a Quick Migration
Veeam will now show the Instantly Recovered VMs with a status Mounted as shown below.
To start the Quick Migration right click on the mounted Instantly Recovered VM and select Migration to production … .
During migration, Veeam Backup & Replication will recover the VM from the backup file and additionally move all changes that were made while the VM was running from the backup in the Instant Recovery mode.
Source: https://helpcenter.veeam.com/docs/backup/vsphere/instant_recovery_review_vm.html?ver=120
Select for the destination a datastore from the Default policy if vCenter doesn’t fully support VM Encryption. If not supported and you nevertheless select here a datastore which is part of the VM Encryption policy, you will run into an error as shown in the troubleshooting section and in the following article by Veeam.
Select the source and target proxy for data transfer, I will leave them by default on automatic selection.
If you want to delete the VM for which the migration was launched (source VM; for Instant Recovery, this is the VM created during Instant Recovery but before finalization), leave the Delete source VM files upon successful migration check box selected. All jobs to which the VM is added will switch to the target VM. The backup chains will be continued, thus, the next job sessions for the VM will be incremental.
Source: https://helpcenter.veeam.com/docs/backup/vsphere/quick_migration_summary.html?ver=120
The Quick Migration has successfully finished and the virtual machine was migrated from Microsoft Hyper-V to VMware vSphere.
The VMDK files were finally migrated from the Veeam backup server and its own NFS datastore to the production datastore in our vSphere environment.
Troubleshooting
To investigate issues you can review the Veeam logs stored under the following directory of the backup server.
%programdata%\Veeam\Backup
Open the folder that matches the name of the job that is having an issue.
Troubleshooting vPower NFS Datastore Mounting Issues
When performing the Quick Migration Job as shown above I was first running into the following error.
Failed to add NFS datastore for NFS host. Failed to mount NFS volume (192.168.195.42:/VeeamBackup_braincloud07.braincourt.de). Fault “PlatformConfigFaultFault”, detail “Operation failed, diagnostics report: Mount failed: Unable to complete Sysinfo operation. Please see the VMkernel log file for more details.: The NFS server denied the mount request”
An error occurred during host configuration: . Failed to mount NFS volume (192.168.195.42:/VeeamBackup_braincloud07.braincourt.de). Fault “PlatformConfigFaultFault”, detail “Operation failed, diagnostics report: Mount failed: Unable to complete Sysinfo operation. Please see the VMkernel log file for more details.: The NFS server denied the mount request”
An error occurred during host configuration: .
The error was also logged in vCenter.
The following article by Veeam will show several steps to resolve this issue. One step is to first check if finally the Veeam vPower NFS Service is running.
Troubleshooting vPower NFS Datastore Mounting Issues
https://www.veeam.com/kb1055
Another step is to try to mount the Veeam vPower NFS datastore manually. Therefore we first need to determine the datastore name and folder name which we can get by the registry and described in the following article.
How to test manually mounting the Veeam vPower NFS Datastore
https://www.veeam.com/kb1284
I also couldn’t mount it manually and was running into the same error.
Solution
In my case finally the reason was that on the Veeam backup server itself also the NFS Server role was installed and using the local TCP port 111. So I just removed the NFS server role on the Veeam backup server to resolve this issue.
The TCP port 111 should be only used exclusively by the Veeam vPower NFS Service as shown below.
Get-Process -Id (Get-NetTCPConnection -LocalPort 111).OwningProcess
A specified parameter was not correct: spec.vmProfile
Select the destination host, resource pool, VM folder and datastore.
Finally the Quick Migration was running into an error as shown below.
Failed to process VM SLES15-SP5-VM02 Error: A specified parameter was not correct: spec.vmProfile (Virtual machine has encryption enabled, but the virtual machine home doesn’t have an encryption profile or doesn’t have a configured security device (like TPM))
The virtual machine is still stored on the Veeam Backup and Replication NFS share.
Solution
Select for the destination a datastore from the Default policy if vCenter doesn’t fully support VM Encryption. If not supported and you nevertheless select here a datastore which is part of the VM Encryption policy, you will run into an error as shown in the troubleshooting section and in the following article by Veeam.
Source: https://www.veeam.com/kb4266
Links
Instant Recovery to VMware vSphere
https://helpcenter.veeam.com/docs/backup/vsphere/instant_recovery.html?ver=120Converting Hyper-V VMs to VMware using Veeam
https://rhyshammond.com/converting-hyper-v-vms-to-vmware-using-veeam/Performing Instant VM Recovery of Workloads to VMware vSphere VMs
https://helpcenter.veeam.com/archive/backup/100/vsphere/performing_instant_recovery_vm.htmlInstant VM Recovery (IVMR)
https://bp.veeam.com/vbr/Support/S_Vmware/instant_vm_recovery.htmlRPO and RTO: What’s the Difference?
https://www.veeam.com/blog/recovery-time-recovery-point-objectives.htmlHow to Convert Hyper-V to VMware VM
https://www.nakivo.com/blog/convert-hyper-v-vmware-vm/
