Hyper V Version2 Update

Editor's Notes

• #2: 64 logical processor support. This is a 4x improvement over Hyper-V R1 and means that Hyper-V can take advantage of larger scale-up systems with greater amount of compute resources. As our friends at AMD and Intel drive up core counts, we want you to know that Hyper-V is ready to take advantage of the compute resources in your server today and those you’re buying tomorrow.Support for up to 384 Concurrently Running Virtual Machines & 512 Virtual Processors PER SERVER. (No, that’s not a typo.) Going hand in hand with our support for 64 logical processors, we’re upping the maximum number of concurrently running virtual machines to 384 per server and the maximum number of virtual processors to 512 for the highest virtual machine density on the market. Here are a few examples. You could run:384 single virtual processor vms OR256 dual virtual processor vms (512 Virtual Processors) OR128 quad virtual processor vms (512 Virtual Processors) ORany combination so long as you’re running up to 384 VMs and up to 512 Virtual Processors
• #3: Introducing: Processor CompatibilityWith Hyper-V R2, we include a new Processor Compatibility feature. Processor compatibility allows you to move a virtual machine up and down multiple processor generations from the same vendor. Here’s how it works…When a Virtual Machine (VM) is started on a host, the hypervisor exposes the set of supported processor features available on the underlying hardware to the VM. This set of processor features are called guest visible processor features and are available to the VM until the VM is restarted. When a VM is started with processor compatibility mode enabled, Hyper-V normalizes the processor feature set and only exposes guest visible processor features that are available on all Hyper-V enabled processors of the same processor architecture, i.e. AMD or Intel.  This allows the VM to be migrated to any hardware platform of the same processor architecture. Processor features are “hidden” by the hypervisor by intercepting a VM’s CPUID instruction and clearing the returned bits corresponding to the hidden features.Just so we’re clear: this still means AMD<->AMD and Intel<->Intel. It does not mean you can Live Migrate between different processor vendors AMD<->Intel or vice versa.In addition, you may be aware that both AMD and Intel have provided similar capabilities in hardware, Extended Migration and Flex Migration respectively. Extended and Flex Migration are cool technologies available on relatively recent processors, but this is a case where providing the solution in software allows us to be more flexible and provide this capability to older systems too. Processor Compatibility also makes it easier to upgrade to the newest server hardware. In addition, Hyper-V Processor Compatibility can be done on a per VM basis (it’s a checkbox) and doesn’t require any BIOS changes.In addition, you may be aware that both AMD and Intel have provided similar capabilities in hardware, Extended Migration and Flex Migration respectively. Extended and Flex Migration are cool technologies available on relatively recent processors, but this is a case where providing the solution in software allows us to be more flexible and provide this capability to older systems too. Processor Compatibility also makes it easier to upgrade to the newest server hardware. In addition, Hyper-V Processor Compatibility can be done on a per VM basis (it’s a checkbox) and doesn’t require any BIOS changes
• #4: We have a script that continuously Live Migrates VMs from one node to the next every 15 seconds. We’ve been running this test for about a week and have successfully completed over 110,000 Live Migrations. Looks kinda like this…
• #5: FAQQ: What happens if a vendor has written an application that uses one of these features that isn’t visible with processor compatibility enabled?A: Since the feature isn’t exposed to the virtual machine, the application won’t “see it” and it’s up to the application to determine how to proceed; however, there are two likely paths…Path 1: The application will check to see if a specific processor feature is available and use it if it’s available. If the processor features isn’t available, it will use a different code path. Remember that applications that make use of these advanced processor features are generally written in a flexible fashion to accommodate the servers in market today and there are still thousands of older Xeons and Opterons on the market that don’t have some of the latest processor features.Path 2: The application requires a specific processor feature and refuses to launch. At this point in time, we haven’t found any application that fall into this category. It’s possible they exist, but we haven’t hit one yet. Since we can’t test every application out there, processor compatibility is defaulted off. (We’re conservative by nature…).BTW, if there were issues with Hyper-V Processor Compatibility, you’d also see it with other virtualization products which rely on underlying hardware capabilities to mitigate this problem as well.Q: Does processor compatibility have a hardware requirement? Does it require Intel Flex Migration or AMD Extended Migration?A: Hyper-V processor compatibility mode has no dependencies on these technologies.Q: Does Hyper-V processor compatibility allow you to migrate a VM from an AMD host to an Intel host and vice versa?A: No. Processor compatibility allows you to move a virtual machine up and down multiple processor generations from the same vendor. It does not allow migrating a VM (with or without processor compatibility mode) from AMD based hosts to Intel based hosts, and vice versa.