Why can't I vmotion between Virtual Center datacenters?

[JonRoderick]

Can someone explain why I'm unable to vmotion between VC datacenters (not physical) when the same storage/networking is in place on the hosts in each datacenter?

Thanks

Jon

[hicksj]

VMware has slowly migrated this functionality up the stack, from limitations to intra-farm, then between clusters, and eventually, I believe they'll allow across Data Centers. Data Center objects were designed to tag physically diverse environments... but with more folks implementing remote accessible and/or synced data, it only makes sense VMotion will eventually bridge data centers as well.

[Dave_Lusty]

This could be that one of the datacenters has EVC switched on, or some other chip compatibility issue. If you plan to use svmotion also check for snapshots.

[JonRoderick]

Thanks - that makes sense but do you know the technical reason for me not being able to carry out a vmotion across VC datacenters?

I can work through the wizard and it fails when I press the last 'Finish'. I'm just curious.

jon

[weinstein5]

I do not know the technical reason but I think this is the last vestage from VC 1.x where you could not do anything between farms (what data centers were called in VC 1.x) with VC 2.x at least we no can cold migrate, deploy templates, create templates between datacenters and vmotion, HA and DRS are last items that do not work across datacenter - my guess is its not technical but more operational - I say this because the requirements for vmotion are critical and by keeping vmotion within the datacenter forces you to make the hardware is compatible -

[Dave_Lusty]

assuming that the chip is the reason, it's because the processors have slightly different features. These features are enabled by the guest at boot, so once it's on VMWare will stop you from migrating in case the same features are unavailable on the new processor.

EVC will help with this within a cluster as it removes features not present on all processors. Unfortunately it does this by looking for the lowest common feature set within a cluster. This means that between datacenters, and therefore clusters, you would have the same problem as before EVC. If the machine was allowed to migrate it could become unstable.

Cheers

Dave

[Dave_Lusty]

cross datacenter migration does work on the current version, and it shows as an extra screen when you migrate.

Cheers

Dave

[weinstein5]

You learn something new everyday - I am just so use to not be able to do it I have never tried -

[Dave_Lusty]

lol I know the feeling! It doesn't really come up that often though as I don't think many people run multiple data centers which they want to migrate between.

[JonRoderick]

Hmm, no such luck here.

When I try it, I get the following error: 'The input arguments had entities that did not belong to the same datacenter'.

I'll reiterate that the hosts I'm migrating to and from have identical networking/storage setups (i.e. all shared) - they were part of the same cluster before I started testing the cross-datacenter migration.

Thanks

jon

[hicksj]

The technical reason is that its not allowed. Unfortunately, it appears that the error presented in VC is not exactly helpful.

[JonRoderick]

Confused now - Dave is saying it can be done, Hicks is saying it can't - one of you is wrong - which one?

Jon

[hicksj]

We might both be right. Confused yet? What version of VC are you at?

[jbsengineer]

I just tried this in my test environment and was unsuccessful. I get the same error. I'm running the latest builds of everything. I do find it interesting that the warning about the "VM Network" not being the same across Datacenters without saying you can't migrate across the Datacenters. (Edit: I'm assuming that you cannot hot migrate across the DC and the warning is built in because you can migrate across cold)

[JonRoderick]

I'm running the latest and greatest VC 2.5 U2 (104215).

Jon

[MMiller9876]

If you shutdown the VM you will be able to move the VM to another datacenter, but you will prompted to change the storage, even if the same volumes/luns are presented to each host