P2V, then replicate - is this possible?

[filipzahradnik]

I am working on a DR strategy for our environment which includes converting physical machines to VMs, then replicating them accross the WAN to out DR site.

I am wondering if it is possible to use Veeam Backup to replicathe the VMs that are created through the P2V process and still get the benefits of incremental replication. I would like to achieve a fully automated 2-step process:

Step 1: Physical server is converted into a VM
Step 2: The VM is replicated accross WAN to DR site

This process would run on a reular basis to keep the VMs at the DR site up-to-date.

I tested this scenario and failed miserably:
I can automate the P2V process for a physical server using VMware vConverter Enterprise. Each time the P2V process runs for this server, it creates a new temporary virtual machine. Once the P2V process successfully finishes, the temporary VM overwrites the previous VM. While the new VM has the same name as the previous VM, Veeam Backup recognizes it as a different machine and replication fails.

Any comments would be appreciated.

[Gostev]

Looks like this happens because when newly P2Ved machine registers, it receives new reference ID from ESX or vCenter. While Veeam Backup job memorizes VMs using these IDs. Potential workarounds which I see include:
1. Run P2V conversion with disabled registration (if there are such option), or
2. Use a script to copy the produced VM files from P2Ved machine to your "main" VM being processed by Veeam Backup, or
3. Use a script to automatically update refID for your replication job after each P2V cycle to the new refID in the Veeam Backup SQL configuration database (unsupported)

[filipzahradnik]

Thanks for the info.

How is the reference ID linked to the VM - is it stored in the VMX file for each VM? The reason I am asking is to see if I can copy the whole new P2Ved VM over the main VM, or just the VMDK files.

[Gostev]

The reference ID is stored in the ESX/vCenter database and theoretically modifying VMX file should not affect it.
But I think best would be to move VMDK files only.