Hyper-V for the ESX Engineer

I just attended a great session on Microsoft Hyper-V. Before I go into my notes, let me give you my background to better frame this post. I used to be an MCSE (NT4!) but I really haven’t touched Microsoft products in a number of years. My focus has been on hardware architecture and eventually this has led me into the virtual architecture as it has gained acceptance into the market place. If some of my highlights seem a little different than most posts out there, it is because I am making the ESX to Hyper-V mapping in my head. I know ESX, I don’t know Windows Server 2008 (or 2003 for that matter).

With that out of the way, here are my points of interest in no particular order.

• Hyper-V is paravirtualized - paravirtualized means the virtual machine is “aware” (Microsoft uses the term enlightened) that it is virtualized. If the machine isn’t enlightened, it will run in emulation mode. Emulation mode requires a lot of context switching between user mode and kernel mode. This will understandably slow down performance.
• The Hyper-V “Service Console” is referred to as the Management Partition. This is a Windows VM with privileges into the kernel that other VMs do not have. This (at least on the surface) is similar to ESX’s Service Console.
• It is recommended to run Hyper-V on Windows Core (stripped down version with no GUI). The core version will consume less resources, require less patches, etc.
• Server 2008 has “roles” that determine the functions on the server. Hyper-V is recommended to be the only role on the server for production
• Hyper-V does not share memory pages
• Hyper-V has quick migration instead of VMotion. Instead of a live migration, the machine is suspend and resumed on another host. The amount of memory will have a direct impact on the amount of time required because the memory contents will written to the disk and then read from the disk on the new host.
• Hyper-V relies on Microsoft Clustering Services right now to provide multiple host functionality for SAN connected virtual machines. This means that Enterprise Edition is the minimum required OS level for the host to perform Quick Migrations
• It is recommended that each LUN contain only one VM. Space needed will be disk space required + virtual RAM assigned to the machine (for quick migrations) + room for snapshots of the virtual machine
• Live Backups of a VM are supported through VSS if the guest OS is VSS aware
• Virtual Hard Disk files are .vhd files instead .vmdk files for ESXRaw Device Mapping (RDM) in ESX is called Pass Through Disks in Hyper-V

At the end of the session we briefly covered the Microsoft Enterprise Management Product (think Virtual Center). It is part of Microsoft System Center and is called SCVMM (System Center Virtual Machine Manager). Here are some points for this product.

• Since Distributed Resource Scheduling doesn’t exist today for Hyper-V, they support the idea of Intelligent Placement of a VM onto the farm. This data is configurable but the SCVMM basically tracks performance of the hosts over a recent time period in an attempt to recommend the best placement of the new virtual machine on a host.
• The entire product is driven by Windows Power Shell and is completely customizable, exportable, etc.
• Upcoming version of the product will support ESX and well as Hyper-V. In order to support ESX, an existing Virtual Center will be required for SCVMM to interface. (Think single pane of glass for management). I have my doubts on this one but I’m curious.
• Self Service Portal - End Users will be able to provision their own machines. Again, I’d have to see this one.

I really enjoyed the presentation and Hyper-V at least has my interest. I’ll be trying to do some hands in the near future. Stay tuned…