Reading Time: 3 minutes

In the last Veeam Community Forums Digest, there are some interesting notes about some possible issues with vSphere Storage vMotion, that usually is used to move backup your VMs in the original datastore during a Instant VM Recovery (IR).

Seems that there is major bug in Storage VMotion functionality of vSphere 6.7 when you are using the optional IR feature that allows you to redirect virtual disk updates to the selected datastore.

Using this option it’s quite common (also if it’s not the default setting) to speed up your VM, as opposed to using the Veeam-provided cache in vPower NFS server, but imply writing delta files on a vSphere datastore.

This setting uses the workingDir parameter to redirect VM snapshots to the selected datastore. This worked fine through ESXi 6.5… but looks like something broke in ESXi 6.7, as now SVMotion just fails on such VMs.

For those already on ESXi 6.7 there are a couple of options available:

  • The first one is obviously to don’t use I/O redirection functionality at all that could be fine if your Veeam vPower repository is fast enough (or if you spin up only few VMs).
  • The second one is obviously to don’t use the vSphere Storage vMotion feature, but instead use the Veeam quick migration option. But remember that unlike Storage VMotion, Veeam quick migration does require a short downtime to switch to the production VM – so schedule it properly.

So it’s just bug that affect vSphere 6.7 version only?

There is still a critical data loss issue around Storage VMotion of VMs with redirected snapshots in vSphere 6.x that is still not fixed by VMware after 4 years.

Again it apply when you are redirecting snapshots, so when you are using I/O redirection functionality. If you are redirecting VM snapshots to the same datastore where you tell VMware to move the VM to, then behavior differs depending on your vSphere version.

Veeam has made different tests and starting from ESXi 6.0 and up until (and including) ESXi 6.7, Storage VMotion reports success without actually moving VM files anywhere.

In this case the solution is to always use the Veeam UI to finalize the VM recovery, because stating with Veeam Backup & Replication 8.0 Update 2, this case will be handled with Veeam quick migration automatically.