Why new replicated VM - move datastore

[SunkistDavid]

V6 fully patched.

At our primary location we moved a group of VM's to a new datastore (LUN) and ESX host and we repointed the Veeam Replication job to the new host. At the remote site where we replicate to we did not change the host or the datastore where being replicated.

We ran into the following problems:

1) We ran out of diskspace on one of our datastores as the replication job layed down a completely new VM when one already existed on the datastore.
2) After the job completed when I reviewed our replication site ESX host I found two (2) of each of the VM's that were replicated the night before. As if the job completely ignored that there was a replicated same name VM already on the datastore and thus I ended-up with an OLD and a NEW same VM.
3) In the replica section of Veeam console I can't distinquish between the "old" VM or the "new" VM so I could delete the old VM and only have one VM layed down at my remote site.

This is not good as this was our first move of 10 VM's and over the next 3 weeks we are going to be migrating 60+ VM. I can't just delete my existing replicated VM's and wait for us to re-replicate Terabytes of VM data. This also has implications if we lose a host at the primary site and the VM's fail to another host will I see this issue when it begins nightly replications?

Why is this happening and why is V6 not recognizing the existing replicated VM at the remote site?

[Vitaliy S.]

Hi David, have you mapped production VMs into existing replicas as it is described in our User Guide (page 118)?

[SunkistDavid]

Where are you looking on page 118 to map production VM's into existing replica's.

On my job on the Virtual Machine section I have a listing of all my VM's that are selected. Here I reselected all my VM's as they were on a different host/different VirtualCenter. There is no exclusions or other settings that were modified.

On the Destination section The Host/Cluster, Resources (we don't have different ones), VM Folder (greyed out) and Datastore were not modified from the original job. In the datastore section no modifications were made by picking datastore for selected virtual disk in either the original job or when I modified the job.

[Vitaliy S.]

Oh....now I see what you're saying, I assumed that you've only changed destination host, my bad

Just to make sure I'm following you - you've re-registered VMs in a different vCenter Server and now you would like to continue running existing replication jobs, right?

[SunkistDavid]

At local site - Moved VM to new ESX host, Moved VM to new SAN, reregistered in new VC
At remote site: Nothing changed we still point to same host and datastore
Then the list of problems encountered when we ran the next replication job.

so right!

[Vitaliy S.]

Ok, thanks for clarification!

Please be aware that when you register a VM in a new vCenter Server, this VM receives a new unique ID (moref number) and is treated as brand new VM, so it is not possible to track and map this VM into existing replica. That is why you now have two VMs on the destination host (expected behavior).

Here is a similar thread about this behavior: Moving VMs to a new virtual center.

[SunkistDavid]

thanks