So what do you lose? According to Woolsey, "we have seen zero application compatibility problems. As many of these features are processor dependent, we believe that any developer looking to take advantage would not want to limit his app to just one processor release. Therefore they would have alternative ways of doing the feature in code and we allow that. Any problems would be handled in the compiler."
Apart from giving Microsoft bragging rights over VMware, at least in the short term, it also allows Microsoft to achieve several other goals. The first is forward compatibility. As you upgrade hardware you no longer need to worry about the migration of your VMs. More importantly, however, is the ability to take advantage of the Cloud.
Both Microsoft and VMware have been playing up the automated migration of VMs into the Cloud. The problem is that the Cloud vendors are not going to commit to ensuring you have exclusive use of a particular processor. They are simply in the business of providing capacity. This feature means you can automate live migration (should you want to) of your VMs.
Woolsey also sees this as being particularly applicable for the SME and other markets where they tend to have multiple generations of computing. One example, given by Woolsey is education where they can now reuse any of their older hardware to run VMs on.
It also turns out that this is part of a separate Microsoft approach that is being bandied about in the R&D and internal virtualisation teams - fluid computing. This is meant to mean 'run it anywhere, everywhere'. It also allows you to choose the right place for the particular workload based on key criteria.
At the moment, if you look at Windows Vista and Windows 7, they give you a performance ranking for your computer based on several criteria including the processor, memory, disk and graphics card. Imagine an application that would do that at a server level. Now you have a level playing field between your servers against which you can now base VM requirements.
If you combine this with your capacity planning you have a deep tool that can use rules to decide on the best place to locate a VM based on realistic data about the platform and the VM. With multi-core processors you could even start to aggregate VMs onto a smaller number of cores, shutting down those that are not needed. You might even discover that a low usage VM is better left on an old server rather than taking up space on your latest, high speed hardware.
