VMware SRM and Data Center Migration

Looking back a few months ago I posted about our Primary Data Center (PDC) migration project, and how we planned to migrate our fairly large VMware environment between datacenters. My initial thought was to extend our SAN's across the 10GbE Metro net (MAN) we have in place and do VMotions and SVmotions to the new hardware in the PDC. While this did seem like a good idea to me in the beginning the powers that be chose to use VMware Site Recovery Manager (SRM).

Let me just state now that SRM has worked great. The ease of use to SVMotion VM's to new "staging area" LUNs and then replicate (HDS HUR and NetApp Snapmirror) those to the PDC was so simple. Then the SRM migrations have been simple as well. The testplan have shown to be a great way to verify everything will work before the actual maintenance window.

Let me just say that I was wrong in thinking the SRM migrations would never work for our needs, but it does. Just another piece of VMware that just works and is very clean in its implementation.

VMware ESX migration..

How are we going to migrate 2 large VM ESX 3.5U2 environments into our new DC?

Well here are the details of the new environment (servers and storage) and my thoughts!

The servers will be HP c-Class Bladesystem with BL460c blades and Intel E5550 Quads. The storage will be Hitachi Data Systems USP-V.

If I extend the SAN from the PDC to our current DC via the 10Gb/s link that runs from the airport area to downtown this will allow me to map new LUNs from the PDC array to the current ESX clusters. Move that direction will allow us to get the first piece of the puzzle completed and that is migrating the data to the PDC. Using Storage VMotion we can migrate the VM data to the PDC USP-V. Now the hairy part, How do we migrate the actual VM's to the PDC servers.

Well if we extend the ESX cluster to the PDC bladesystem over the 10Gb/s link that should work just as if we were extending the cluster from one side of the DC to another. OK so technically that all should work. What about the CPU differences? Currently the ESX clusters run on X5355 Intel Quads and according the the VMotion CPU Compatibility Requirements for Intel CPU's this will be a problem.

Intel Core CPUs

VMotion CPU Compatibility Group	CPU Details	ESX 4.x, ESX Server 3.x, and ESX Server 2.x
Group A	Without SSSE3, SSE4.1, or SSE4.2. Models include: Dual-core Xeon LV based on Intel Core microarchitecture. For example, Sossaman.	For A<->B VMotion, apply SSSE3 mask. (Not supported)
Group B	With SSSE3. Without SSE4.1 or SSE 4.2. Models include: Intel Xeon CPUs based on the Intel Core microarchitecture. For example, Intel Xeon 30xx, 32xx, 51xx, 53xx, 72xx, or 73xx.
		For B<->C VMotion, apply SSE4.1 mask. (Not supported prior to ESX 3.5. Experimentally supported for ESX 3.5 and later only.)
Group C	With SSSE 3 and SSE4.1. Without SSE4.2. Models include: Intel Xeon CPUs based on 45nm Intel Core microarchitecture. For example, Intel Xeon 31xx, 33xx, 52xx, 54xx, or 74xx.
		For C<->D VMotion, apply SSE4.2 mask. (Not supported prior to ESX 3.5. Experimentally supported for ESX 3.5 and later only.)
Group D	With SSSE3, SSE4.1, and SSE4.2. Models include: Intel Xeon CPUs based on Intel Nehalem microarchitecture (Core i7). For example, Intel Xeon 55xx.

So now what to do? Will this not actually work or just not be a long-term supportable configuration? Feasibility vs Supportability! I just need it to be feasible.

I have mulled over SRM for migration as well. While it's possible it will require a TON of pre-work to get specific move group VM's onto the same LUNs and will require outages, which I guess are ok, but I just think its really cool to be able to do it all without downtime.

To be or Not to be...