A. Typically, collections of virtual servers such as a Hyper-V or ESX Cluster would have nodes that all have exactly the same hardware, including the same model of processor. However, as environments expand, you may add new nodes that have different processors.
Consider how a virtual machine (VM) works. The VM is turned on, its virtual BIOS boots, and the OS loads and performs various hardware checks. You then start an application in the VM, which may check the capabilities of the hardware and the instructions supported by the processor to enable enhanced functionality. Now imagine this VM is moved, using a zero downtime technology such as vMotion or Live Migration, to a node in the cluster that has an older version of the processor. This older processor is missing a set of instructions that the application found to be available when it performed its hardware check. The VM doesn't know it's been moved to a new virtual host, nor do the OS or the application. The application tries to use some of the enhanced instructions on the CPU, but they're no longer available and the application crashes. This isn't a good scenario.
To protect against the above scenario, it wasn't possible to perform migrations (vMotion, Live Migration or Quick Migration) between hosts that didn't have the same processor version in ESX 3.5 and Hyper-V 2008. However, this requirement proved very constricting.
ESX 4.0 introduced Enhanced VMotion Compatibility and Hyper-V 2008 R2 introduced processor compatibility mode, both of which accomplish the same thing. These technologies hide the true processor in the hardware from VMs, and instead tell the VMs that the processer is a lesser version with a limited set of instructions. This makes it so that all hosts in the cluster support the subset of instructions shown to VMs, enabling zero downtime migration between different versions of a processor.
Note that you can't move between AMD and Intel processors with these technologies, but you can migrate from processors such as the Intel Core i7 to a Core 2 Quad (as in my lab).
So back to the question: is there a disadvantage? The answer is probably obvious at this point. The technology works by hiding advanced instruction sets from VMs. You may have a brand new, state of the art CPU in a server with instruction sets that would make applications run twice as fast, but the VM won't see them and won't be able to use them. It's a tradeoff between functionality and portability.
Related Reading:
- Virtualization Myths and Misconceptions
- Q. I'm seeing a big performance difference with my live migration operations when I use Cluster Shared Volumes (CSV), is this normal?
- Q. How can I list all applications being published from a Windows Virtual PC virtual machine (VM)?
- Q. Why are my virtual machines (VMs) migrated between nodes in a cluster using Quick Migration instead of Live Migration when I shut down a cluster node?
Check out hundreds more useful Q&As like this in John Savill's FAQ for Windows. Also, watch instructional videos made by John at ITTV.net.
