Really weird vmotion-related failure

[pufferdude]

I had something occur this weekend that I can't explain. Wondering if anyone else has seen something similar...

I have a simple two-host vSpher 5.1 setup, and last Friday I manually vmotioned all VMs off one host, patched it, vmotioned all VMs to newly-patched host and patched the old one, then vmotioned the VMs that belonged on that host back. Simple.

The weird part is when veeam 6.5 ran the job to back up my vCenter VM. Since such a VM has to be selected from its host directly and not via a folder or other mechanism, you'd expect that Veeam wouldn't be able to "find" the vCenter VM anymore post-vmotion... but when the job ran, it said it could not find a COMPLETELY DIFFERENT VM! I opened the job and took a look, and sure enough one of my other VMs completely unrelated to vCenter was "selected" (and the vCenter VM wasn't in the selection at all.)

Obviously simply choosing the vCenter VM from its host again got me back up and running for that VM's backup, but I'm confused as to how/why veeam showed a completely unrelated VM in the job as the one it thought it was supposed to back up, after simply vmotioning the VM off its host and back? Is this anything to worry about, or a random "glitch"?

[veremin]

Most likely this issue was caused by upgrade process, though, the reasons of particular behavior are not that clear. I’d recommend contacting our support team with it, since log or SQL database investigation seems to be required.

Thanks.

[foggy]

Looks like some kind of mo-ref ID confusion took place due to some reason, I agree, it definitely worth contacting support.