Hot on the heels of my post a couple of days back, about Core Parking, I’d like to add to that, some information around some of the other CPU-related enhancements that are coming in the R2 wave.
The first, is the increase in the number of logical cores supported in the Hyper-V R2 parent OS. In Hyper-V V1, which shipped as part of Windows Server 2008, we supported 16 cores in the physical server, however that quickly grew to 24 cores, with the addition of a hotfix. The plan of action for R2 would be to extend this to 32 cores, however the Hyper-V team have extended well past that mark, and when R2 ships, we’ll actually support 64 logical processors in the physical server, which is a great example of high scalability and puts us on a par with the upcoming vSphere release, from VMware. It’s also important to note, that Windows Server 2008 R2 as on OS, without enabling the Hyper-V role, will actually support up to 256 cores. At the current levels of cores per CPU, that’s still a hell of a lot of CPUs!
So what does this mean in terms of the number of VMs I can run?
Well, how about:
In all honesty, when you get to numbers this high, it starts to get a bit crazy, and it’s unlikely that anyone will run that number of VMs on a single server on any virtual platform in production for a good while yet – think how much memory you’d potentially need! Obviously not much if you wanted to run 384 x 8mb RAM VMs :-) In fact, you’d only need about 100GB RAM to get 384 x 256mb RAM VMs running, so perhaps not as unrealistic as I first thought! Still, I don’t have 64 cores do I!!!
With the inclusion of Live Migration, the matching of hardware, particularly CPUs, within your Hyper-V cluster becomes even more important. You wouldn’t want to Live Migrate a VM from a newer CPU Host, to an older CPU Host, to find that it results in a failure because a feature of the CPU on the newer host, wasn’t present on the older CPU host. Ideally, a check should be performed to ensure that migrations only take place if a level of compatibility is in place between your hosts CPU’s, but that suggests that if the check is performed, and the move is deemed incompatible, that there would be no way to migrate the VM between that particular source and target. That isn’t good enough. Thankfully, it isn’t an issue.
Processor Compatibility mode is a feature that is set on a VM by VM basis, and basically, ensures that if you want to migrate a VM between hosts that have slightly different CPU feature sets, Hyper-V only exposes the common CPU features to the VM, ensuring migration compatibility. It’s not magic, so it won’t provide an Intel –> AMD migration, or vice versa, but it will for example, allow scenarios like:
This is one of the test cases that has been performed in Redmond, but not just a few times. They’ve been migrating VMs, every 15 seconds, between these different hosts on a 1GB iSCSI SAN backend, for a week now, topping over 110,000 Live Migrations between these different CPU architectures.
This capability, like I said, is enabled on a VM per VM basis, and isn’t to be confused by similar, hardware based approaches from AMD (Extended Migration) and Intel (Flex Migration) which are enabled per host, in the BIOS.
You can read more about Processor Capability on the Virtualisation blog, and also hear about it in one of my upcoming demo video’s.
PingBack from http://up2v.wordpress.com/2009/05/17/hyper-v-r2-compatibility-mode/