Backstory: I have two discrete vCenter servers, we'll call them vcA and vcB. I setup a third server, vcC, in the same SSO domain as vcA now with linked mode! I would like to migrate guests from vcB to vcC live. (All vCenters are 6.0 U2 on Windows, and all hosts are ESXi 6.0.)
There is a script written by virtuallyGhetto to do such a thing. I have a four-node cluster that I'd like to start with. I moved all the guests off of the first host, disconnected it from vcB, and landed it on vcC. The host has all the same networks (I exported / imported the Virtual Distributed Switch configs) and I left same datastores intact. I re-wrote the script to match up the distributed port group, and individual datastore IDs per disk from the source to the destination vCenters. When I ran the script against a test VM, it migrated successfully.
When I tried another VM migration, it failed complaining about not enough space on the target datastore. I checked and the datastore for this VM was 70% utilized. The datastore for my test VM was only 25% utilized. Eventually, after trying a few things, I increased the size of the datastore so that it had >50% free space, and the migration succeeded.
I watched the datastore during the vMotion and I didn't see any sign that files were actually copied. The VM is ~5 TB in size, but the migration took 1 min 16 seconds. Our network isn't that fast. At this point I'm thinking that the RelocateVM_Task does pre-checks for target datastore size, without taking in to account the possibility that a storage vMotion will not be required.
Have I missed an option on the VirtualMachineRelocateSpec? Or on the VirtualMachineRelocateSpecDiskLocator? Someone on another forum suggested this was a bug which may be fixed in 6.0 U3.