Confusion on Veeam Replication Jobs & Compute vMotion

[FCU_JE]

Related case 07452987. Running VBR 12.2.0.334 or whatever the latest version is that had security updates the other month.

I've inherited an environment where Veeam Replication is in use to replicate vSphere VMs from one datacenter to another. I'm relatively new to the replication part of Veeam but not new to Veeam itself or vSphere.

For context, we have the vCenter server added to the Veeam inventory (not the individual ESXi hosts) and the VMware proxies are setup in hotadd appliance mode. All VMs and VM disks are backed by shared storage/VMFS datastores.

What I accidentally discovered and don't understand is that while Veeam is replicating a VM, I can't use vMotion to migrate the compute of a source or replica VM from one host to another.

I want to be clear - this is when no snapshot operations (create/delete/rename) are occurring or anything else is occurring with the VM apart from its general operation. While there are open snapshot(s) on the VM(s), my understanding is the hotadd Veeam/vmware proxy is attached (read only) to the base disk and not to anything the live VM is actually using.

After the replication job is done with the individual VM in the job (done with all the snapshots), I am free to compute vMotion the VM again between hosts again like normal.

Have I stumbled across a bug? Is there some misconfiguration in this environment which prevents vMotions of VMs during replication jobs? My assumption here would have been that because the proxy is doing all the heavy lifting and it's attached to vdisks like any normal VM is, there's no reason I shouldn't be able to vmotion the source or replica VM between hosts.

Have I got something fundamentally wrong? Is this expected behavior? I need to know if I need to put effort into bettering my understanding or correcting the environment before I go any further with the support case.

[Andreas Neufert]

No, this is normal. With "global.methods" permission we set a flag to the VM that it can not be used with vMotion or Storage vMotion (RDS can not move the VM as well but VMware HA can of cause) during backup or replication processing. We remove the flag at the end of the job.

This is needed to ensure that the backup operation is not interrupted and can fail and documented by VMware as a requirement for (backup) processing.

In theory you can create a vcenter user and do not give us the "global.methods" rights to prevent this, but you would need to deal with failing jobs and potentially broken replica chains when you migrate VMs under job processing.

[FCU_JE]

Hi, Andreas

Thanks for the response. Maybe this is quickly turning into a "feature request" based on your reply.

I do get that there are a lot of variables that have to be considered by engineering if they were to consider this and it sounds like this is a requirement imposed by VMware. I quickly reviewed the below article as provided to me by Veeam support under the case and while I'm not a programmer/dev/software engineer, this does feel a bit strange to me. Any normal VM can be vMotioned between hosts no matter how many snapshots it has (so long as the compatibility is sane, obviously) so I'm personally confused/ignorant as to why VMware states the latter requirement in this quote: "Call this function after closing all the virtual disks, and after deleting the virtual machine snapshot"

https://docs.vmware.com/en/VMware-vSphe ... D3394.html

For a bit more context on my motivation here - the replication jobs in this environment are not fast. Some of the VMs in my replication job take up to or over an hour to replicate. When I wish to do maintenance to the VMware environment, I can be prevented by doing much of anything when Veeam is locking my ability to evacuate a host for maintenance.

Personally it feels to me like this rough process would be fine for the type of situation I describe (use of hot add proxies and shared datastores):

1. Veeam locks the VM from vMotion and other tasks via PrepareForAccess

2. Veeam does whatever it normally does to the VM - snapshot creation, VM reconfigurations, etc

3. Veeam unlocks the VM for vMotion and other tasks via EndAccess.

4. Veeam completes the tasks on the VM disks (maybe steps 1-3 are in a for loop until all disks are completed due to the configurable task limits).

5. When done with the VM in a given job, Veeam locks the VM from vMotion and other tasks via PrepareForAccess

6. Veeam does whatever it normally does to the VM - delete/consolidate snapshots, VM reconfigurations, edit notes field, etc

7. Veeam unlocks the VM for vMotion and other tasks via EndAccess (as it does today).


I am certain I am making loads of assumptions here and might be playing the part of a fool. What I'm really wanting to get across though is right now, Veeam prevents me from doing other operations in my vSphere environment when it's otherwise safe to do so.

[Andreas Neufert]

I would address the evacuation situation with some RDS rules, where the VM is automatically moved when it can be moved (after Veeam processing).

Veeam and all other VMware backup software use the VDDK SDK kit from VMware to interact for backup with the vcenter and ESXi hosts.
The major part in the processing of this VDDK kit is focused on the specific ESXi host.
If you want to change this situation, you would need to open feature request from VMware to change this dependancy. I agree for HotAdd or DirectSAN processing it does not look that obvious as a requirement, but I think in total,the intention is that during vmotion there is a lot of metadata changed as well that would lead to an inconsistency for metadata information. Remember that we process metadata like VMX files and other things during the backup process and these are not included in the snapshot.