Mike D’s Blog

I was at a customer this week that told me Microsoft could migrate live between AMD and Intel processors and asked why we (VMware) couldn’t. I actually get this question a lot and so I’m providing some context to the answer here. Microsoft and XenSource and all of the other competitors out there that do some sort of “live” migration run into the exact same issues that we do. Here’s what’s happening. Basically you’re running an OS on an Intel box and let’s say the processor supports the SSE3 instruction set and your app happens to use that instruction. Now you migrate that to an AMD box that doesn’t support SSE3 but the app is still using it and trying to use it. BAM! Your app and your OS will crash. This can happen with VMotion and Microsoft Quick Migration. Actually anyone that does live migration will get impacted by this. There are several “user mode” instructions like this that we can’t mask out at the virtualization layer.

At VMware we are always conservative so we check for this incompatibility before we let you shoot yourself in the foot potentially. With the Xen based live migration and Microsoft Quick Migration they do not perform the check and so you can actually do the migration but your app and your OS may die as a result.

Actually, in the VC config file you can put in a parameter to prevent VC from doing any checks. With that parameter you can do migrations between anything you want. Just be aware that you may shoot yourself in the foot and it’s not supported as such.

With all of that said, VMware went to the chip manufacturers a while ago to see if we could get a switch where we can turn their advanced features off. They laughed at us originally. Who can blame them. They put the advanced features in there to differentiate themselves and sell processor upgrades. We’re basically telling them not to be competitive. Well, with virtualization showing up everywhere the chip manufacturers have decided to put advanced virtualization capabilities into the chips. It all started with Intel VT-x and AMD SVM. Now both manufacturers are including a switch that will allow us to turn off certain features and make the processors look like they have the same features. Intel and AMD have both added this feature to their recent processor launches. This is really great since now you can buy a new box with a new feature set, add the box to the virtualization cluster, and we’ll go ahead and turn off the advanced features that would normally prevent migration. We can set everything to the lowest common denominator.

I know what you’re thinking. Won’t this be bad because my apps use that feature. Truth be told most of the user mode functions are used on the desktop side primarily. Some server apps still use those advanced features as well but not so many that you need to worry about it. Most of the user mode stuff deals with video and so it’s not terribly useful on the server side. With over 6 million Windows apps and probably twice that on the open source side it would be impossible to create a list of which apps use which features. This is why we do all of these checks in the first place.

Anyhow, that’s why we say you can’t migrate from Intel to AMD just yet and this is why anyone that says they can do it is lying to you or just don’t understand the technology. The later happens to be true with most of VMware’s competitors – especially the field sales. I guess that’s where experience comes in.

I hope that puts some context around this.

Finally someone can just post a correction without getting emotional about it. Virtual PC Guy posted a great explanation of why Microsoft checks for the CPU compatibility that falls right in line with the reasons I outlined here. I’m not sure why my original setup did not check for CPU compatibility. I’m also not sure why the guts of Quick Migration and failover – HAVM.vbs found at the end of the instructions for setup – does not clearly show anywhere that a check occurs. Never-the-less, if you happen to try migrating between incompatible processor types then you get the following warning in the interface followed by a VM left in a suspended state and awaiting instructions on where to go and run:

Thank you Virtual PC Guy!!

No on to the XenSource camp. Like I said before I love it when I get Simon excited. To his defense I was using an older version of XenSource and relying on some experience with open source implementations in RHEL5 and SLES10. The RHEL5 and SLES10 implementations still do not perform CPU checks or if they do they certainly don’t tell you about it or warn you when you do a migration. Thankfully my test VM was a simple RHEL5 guest and just migrated between the Intel and AMD systems I had without worries. No warning. No caution. Just migrate. My XenSource 4.1 install did produce a warning when adding the AMD host to the Intel cluster.

I stand corrected on the new processor check feature.

I do question Simon’s memory. In his response back he says:

The total number of patches shipped to date for XenServer: 0. Total hot fixes andpatches shipped last year for VMware VI3/ESX alone: 68*!* of which 17 were critical. Silly me! Those were probably only “feature enhancements”.

Simon, what are all of the hotfixes listed here for XenServer? I guess those are “feature enhancements” as well.

And, oh, you might want to look up what FUD is. This wasn’t FUD. This was just bad blogging on my part and not checking the most recent version of software for one vendor and it failing for another vendor. There’s enough FUD going around from the Citrix and Microsoft field teams telling customers you can migrate between CPU families and VMware can’t. That’s what prompted this post in the first place. Perhaps you can help me out with that while you’re charged up with energy.

For more in-depth information on CPU compatibility with VMotion see the following paper: http://www.vmware.com/resources/techresources/1022.

Tags: live migration, quick migration, vmotion