Cross vCenter vMotion and MoRef ID

[jessethomas]

Hi Everyone,

We have two data centers which are connected via a high-speed L2 interconnection. Each data center has it's own vCenter appliance, but they are connected together via enhanced linked-mode and in the same SSO domain. One of the features this architecture affords us is the ability to storage and computer vMotion running guests between the data centers, which we do on occasion to re-balance workload.

We also backup guests in both data centers using B&R 9.5 using tags. This means that Veeam will locate and backup the guest regardless of which datacenter or vCenter it's located in. However, when we vMotion guests between data centers, their MoReF ID is being regenerated, which causes Veeam to see them as a new guest. This creates a new backup chain, which requires a new full backup and causes orphaned retention points. Especially for guests with significant storage, this causes a lot of overhead on our backup storage and is difficult to manually purge out over time.

Does anyone with similar architectures have any other techniques for migrating guests in a way that either doesn't change the MoRef, or re-links Veeam to the new MoRef so a new backup chain is not started? I am aware of the migration utility/script, and we've used this in the past, but I'm hoping for something a bit more elegant.

[foggy]

Hi Jesse, I'm afraid nothing you can do here, since VM gets new ID upon being registered in another VC and there's no easy way to match ID's in Veeam B&R database either (unless you do this manually).

[jessethomas]

Thanks very much for your reply foggy.

I realize that this is likely not a problem for many Veeam users, or at least not a problem that is encountered often, but I'm wondering if this is an area where a future enhancement to B&R might be made? I understand there is some risk with any mechanism for "re-linking" guests with different MoRef IDs, but perhaps there could be a way to "soft-link" them so that at least old retention points could be purged out?

We fortunately use deduplicating storage so the impact isn't crippling, but it does require a manual process for us in an otherwise very reliable and hands-off system.

I would be more than happy to write-up and submit a feature request if there would be any traction for it to go anywhere. But, I can also see where this might be too much of an edge case to be useful for a critical mass of users.

Thanks again for your reply.

Kind regards,

[foggy]

I understand there is some risk with any mechanism for "re-linking" guests with different MoRef IDs, but perhaps there could be a way to "soft-link" them so that at least old retention points could be purged out?

Old restore points for VM with an old ID value will be subjected to deleted VMs retention.

I would be more than happy to write-up and submit a feature request if there would be any traction for it to go anywhere.

Your post is already considered as feature request, so thanks for the feedback.

[bdufour]

i had to create a cname record in DNS pointing my old vcenter server name to the new one - the only way i could leverage CBT for my replicas on the first pass. there was no way i could have re replicate all of our data again. seems like you have more than one live vcenter server though, i only have one. i can confirm that restores also work after the cname record. basically, i wanted to migrate to the new appliance from a windows based deployment. many problems arose with vmwares migration plan of action and they insisted on deploying the appliance from scratch (which is a very common thing for them to do so beware). that worked great, had the host migrated and everything set up in less than an hour. veeam didnt like that though and seen them as all new vms in its database bc of UIs/morefID. i had to edit all of the jobs as well, re pointing them to the old vcenter server name, i have it down to a science now.