Among other things, vSphere Affinity/Anti-Affinity rules are indeed preserved with a Virtual Machine during a Cross vCenter vMotion (xVC-vMotion) which is a new vMotion capability in vSphere 6.0. If you wish to learn more about this awesome new feature be sure to read about it here and here.

There were a couple of people asking about the details on how this actually worked so I figured I would set this up in my lab and provide some additional information. In my environment I have two vCenter Server 6.0 joined to a single Platform Services Controller (same SSO Domain) which provides me with the Enhanced Linked Mode capability which is one of the requirements for a regular xVC-vMotion as it needs to be visible in the vSphere Web Client. You can also do an ExVC-vMotion, which does not require the vCenter Servers to be part of the same SSO Domain, you can find more details in this blog post here.

I initially had 3 Virtual Machines called: Web1, Web2 and Web3 which ran in my "PA-VSAN-Cluster" which is located in my first vCenter Server. I then create an Anti-Affinity rule called "Web-Rule" that ensures all three VMs are running on separate ESXi hosts. I then manually perform xVC-vMotion (remember automated DRS migration is on a vSphere Cluster boundry and will not vMotion outside of a vSphere Cluster or vCenter Server) each VM to my secondary vCenter Server to my "SB-VSAN-Cluster"

Once the VM has successfully relocated to the destination site, the Affinity/Anti-Affinity rules are then migrated over. You might be wondering why the Affinity/Anti-Affinity rule could not be created in advance and the reason is because it needs the actual VM object to be available to associate the the rules to. Once all three VMs have been migrated over, you will see that the old Affinity/Anti-Affinity rule no longer exists in the source vCenter Server and now lives in destination vCenter Server as seen in the screenshot below. Simple and elegant!