Sharing of thoughts and information is what blogging is all about. This way we can learn from each other. Post A Comment!These postings are provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use.
Anthony Bartolo Twitter | LinkedIn
Pierre Roman Twitter | LinkedIn
It is pretty well known that for Live Migration to work in Hyper-V, the CPUs on the hosts must be of the same family (Intel to Intel, AMD to AMD). However it is not as simple as that.
Both companies are constantly improving their products, so a CPU that Intel makes in 2013 will have more features than one they made in 2010, and because of that they will not be compatible for Live Migration. In theory then, the Live Migration window is really closer to eighteen months before you are out of band.
So how impractical would it be if both VMware and Microsoft told companies that in order to have Live Migration their servers had to be less than eighteen months apart? So several years ago Intel and VMware got together and addressed the problem. The result was what they called Enhanced vMotion Compatibility (EVC). Essentially what they do for servers in a cluster where EVC is enabled is they simply mask the advanced features of the newer CPUs, which are usually only needed for sound and video and thus not for the majority of business servers.
Microsoft then introduced Hyper-V, and overnight (five years later) they are a real player in the virtualization realm. In fact, there are some people who would say that they are equal to or better than VMware. They need to implement a similar feature to prevent the same issue. Unfortunately they can’t call it EVC because that includes VMware’s trademark vMotion. Being better with technology than they are with marketing, they settled on calling it ‘Migrate to a physical computer with a different processor version…’ or MTAPCWADPV. Try to say that three times fast ;)
While their feature name is nowhere near as easy as the equivalent from their competition, the technology is applied to the virtual machine rather than to the cluster. So in your environment you could have a cluster where some VMs could migrate to some hosts but not to others.
Now here’s the misconception: People seem to think that by enabling MTAPCWADPV you are sacrificing performance on your VMs. Nothing could be further from the truth.
The performance reduction of CPU compatibility mode is a myth. What MTAPCWADPV does is it masks the newer features of the CPU – mostly multi-media signatures and such – but does not otherwise hobble the CPU. Unless your VM requires those newer features there will be absolutely no performance decrease to the VM. If they have VMs that DO need the newer CPU features then leave those on the newer blades.
The other myth, of course, is that it allows you to Live Migrate from Intel to AMD or vice versa. Unfortunately that is not possible. Will it be in the future? Who knows… but under the hood the two families are still different enough that I don’t expect to see it anytime soon.
That’s it! The only caveat is that the VM must be turned off before you do it. Messing with the processor is not something you want to do live ;)
Live Migration can be performed between any servers with compatible CPUs… as long as they are within the same family. Try it yourself!
Nice summary and history of Compatibility Mode.