The long awaited to refresh to the Hyper-V virtualization hypervisor in Windows Server 2008 has finally released! Although it came more than the expected 180 days after Windows Server 2008 RTM'd, my progression from a beta to RC to the RTM version has actually gone quite smoothly. I wanted to share a few thoughts from my first week with the RTM product, as I know there are going to be a lot of folks looking at Hyper-V as an option for virtualization in environments that principally use the Microsoft stack of software products.
Falconic Note: Note that this is the first article to go in my Virtualization category. My engineering specialties have been Security, Virtualization, and Messaging for a while so I figured that it would be appropriate to have a category for each and since Security and Messaging already existed here, I needed a virtualization category for my muses on Hyper-V, VMWare, etc.
Falconic Note 2: You can find out more about Hyper-V from Microsoft's product feature page and download the RTM from the download center.
Hyper-V as RTM, Care in Installation
When I was playing around with the release candidate of Hyper-V, I have principally stayed with three VMs in my lab environment.
I use a Windows Server 2003 virtual machine for working with scripts and so on for the 2003 platform, a Linux VM which allows me to maintain the (frankly, relatively thin) skills I have on that platform which I have retained from my multi-platform work early this decade. This Linux VM also hosts some of my Linux-specific platforms such as my uptime and connectivity link monitoring for my home network. For those that care, the distribution I have running is Fedora Core 9 with SELinux/Audit services turned off. The third VM which I am hosting is a Windows XP workhorse that hosts the few applications I have that do not play nicely with Vista including Zend Studio Client which I sometimes use to supplement Microsoft Expressions Web 2 in my web development work.
Three VMs. 512 MB of memory on each. My Linux VM is set to use a static MAC address and uses the legacy network adapter in order to avoid some of the compatibility bits in working with Linux on Hyper-V.
The underlying hardware platform is a Windows Server 2008 x64 box that I built myself:
- Athlon 64 X2 6400+ (3.2 GHz)
- Abit KN9 Ultra Motherboard
- 4GB DDR2 @ 667MHz (Non-ECC)
- 80 GB Logical OS Drive (RAID 1 Mirrored array using 2 physical hard disks)
- 1.2 TB Logical Data Drive (RAID 5 Striped with Parity array using 4 physical hard disks)
- Radeon X300 for console video
- 2 x 1Gbps Onboard LAN (RealTek)
Falconic Note: Don't buy an Abit motherboard. They take forever to release BIOS updates, all of their support operations are based out of Taiwan and the support experience is VERY frustrating.
When I went to install Hyper-V, I was infuriated by the process. All those who are using re-purposed hardware from a Windows Server 2003 server, you need to make sure that you have gone every step of the way to ensure that the Operating System has full access to the eXecute Disable (XD) bit, also called Enhanced Virus Protection or EVP by AMD, as well as the Virtualization features on your server's processor. When I installed Hyper-V for the first time, I was stymied for a long time on making the XD and Virtualization features available properly to the operating system. This is the main problem that I am seeing and hearing that people are getting stuck on when installing Hyper-V on a Windows Server 2008 machine.
If you run into problems using Hyper-V, look for these errors in the event log:
- Error ID 51: Hyper-V launch failed; virtualization not supported or enabled on processor 0x0 (check BIOS settings).
- Error ID 42: Hyper-V launch failed; Either SVM not present or not enabled in BIOS.
If either of these two errors exist, the virtualization features from AMD-V or IntelVT on your processor are not making it through to the operating system. The first thing to look for is make sure your hardware will support virtualization. This is particularly true on an Athlon processor as many of the AMD Athlon processors use something called "F2" stepping. Processors which are "F2" processors have a problem in the way that AMD-V is implemented, making their use for virtualization completely dependant on proper support from the BIOS. You know you have an "F2" stepped processor if your processor is:
- Athlon FX-62
- Athlon 64 X2 5200+ or lower
Even though the installation instructions on the Hyper-V mini-site for Windows Server 2008 start with the actual steps to enable the Hyper-V role, I would strongly encourage you to take the extra minute to do the following first steps to prepare your server:
- If necessary, replace your Athlon F2 processor with an Athlon F3 processor to reduce compatibility issues. Opteron and Xeon processors should be preferred over Athlon and Core2 lines of consumer processors as it is easier to obtain support on server processors. Microsoft tech support and computer enthusiast support channels will blame that first before even trying to help with the issue.
- Update your server motherboard to the absolutely latest version of the BIOS
- After the update, enter the BIOS and check for supported features.
- Note that some BIOS may require you to "Disable" a Negative feature rather than "Enabling" the feature. This can be a point of confusion.
- Virtualization must be enabled.
- Execute Disable, Security Bit, or Enhanced Virus Protection, or whatever the other terms used in your bios for the eXecute Disable bit must be enabled.
- Install a clean installation of Windows Server 2008.
- Run a BCD Edit command to force the nx attribute to always on.
- Run a command window as administrator.
Go to Start. Right click on "command window" and choose "run as administrator".
Choose to confirm starting the window with administrative privileges.
- Run the command:
bcdedit /set {current} nx AlwaysOn
- Verify the setting by typing:
bcdedit /enum
- The output should look similar to the following. Note the nx setting which I have boxed in orange on the screenshot. This is the key setting we are looking for.
- Use an application like the "Hyper-V System Compatibility Check Utility available from the AMD website to ensure that the features show available to Windows Server 2008.
AMD-V_Hyper-V_Compatibility_Check_Utility.zip
- Once the features are verified, at that point, I would pick back up on installing the Hyper-V role on your Windows Server 2008 machine.
Stomping the Bugs from Beta and RC Code
During the beta and RTM phases, there were a number of bugs, particularly related to processor utilization and prioritization, that seem to be fully addressed in the RTM code thus far.
First, the server is stable under RTM. This is a great improvement over beta and a slight improvement under the RC. (The RC was mostly production ready so it was fairly stable but I did run into a couple of minor annoyances in this respect.)
Under the beta, you could create a processor domination condition where a single VM ran something crazy like an application with an unterminated loop that went through processor-intensive math instructions. The result is that the guest VM would fully occupy the CPU and the hypervisor would not re-assign it to other VMs who were attempting to interrupt with their own activities. See the problem? Under the hypervisor model, from the HV layer perspective, the "host" console is a VM instance too! That's right, a condition where the console could be locked out and unresponsive because of a race condition in the VM! In the RC this was fairly arbitrarily handled in that the system became chunky. Other VMs could force actions through however in my testing, I could clearly tell when the VM I was using was getting processor time in near-real-time. I would get a pop of responsiveness, a pause, and then a pop again. In the RTM this seems to be handled a little more smoothly. Other VMs will slow down slightly but this is the expected behavior when the overall system is in use. The Host and other guest VMs will have a uniform slowness to responding to actions.
RTM plays nice with snapshots. I have used the snapshot functionality to save milestones for my VMs where the VM was constructed with all of the necessary applications. And then another for each VM where the applications and operating system were fully configured. On two occasions, I have forced a condition where I intentionally messed up the disk and reverted to snapshot. Each snapshot reversion worked as expected with no unexpected defects I could locate in the VM itself. The primary things that had to happen were updating the clock on the VM, updating the virus signatures for the antiviral application, and on one occasion, rejoining the machine to the domain.
Hyper-V versus VMWare VI 3.5
Hyper-V is not at the scalable enterprise-class of VMWare. Its not. Sorry. VMWare is still the clear leader in the space as the VMWare Infrastructure services offered in 3.5 have the scalability, migration, and management functionality that make it an ideal choice for data center consolidation efforts. With VirtualCenter from VMWare in concert with VI 3.5, you have the ability to do relatively easy P2V, V2V host migration, guest load balancing among hosts, disaster recovery by near-automated V2V host migration, not to mention the integrated monitoring and health capabilities the VirtualCenter infrastructure offers.
The flip side of the deep VirtualCenter capabilities in 3.5 is that if you do not have a VC server in the environment, the benefit that you earn for upgrading from VI 3.0 to 3.5 is mainly geared in bugfixes and compatibility. Microsoft has released a number of supporting features to make Hyper-V more attractive to the enterprise computing environment. For one thing, there is a management pack available now for Hyper-V for System Center Operations Manager as well as the System Center Virtual Machine Manager (with the Hyper-V RC1 patch from the Microsoft Connect site which also works for RTM for now) which offers a consolidated application for concentrated VM management but is not yet the enterprise class product that VirtualCenter has become for VMWare. The Hyper-V WMI APIs are also now available from Microsoft for developers interested in building custom applications or system support into existing applications.
There is also one other clear differentiator. Linux. Microsoft has chosen to support only one Linux distribution, from a partner which it has signed an IP agreement with. And you can't use just any old version of the SuSE Linux distribution, it has to be one of the supported and purchased distributions. This is one of the key sticking points to getting Hyper-V adoption in many data centers. I have personally tried to start several Linux and other free operating systems on Hyper-V. Certain distributions like RHEL and Fedora I could get to work with a little bit of messing about. Some distributions and platforms, such as the beta of OpenSolaris, I could not force to function without investing more time in the build and troubleshooting effort than I was willing to invest.
Falconic Note: For any Linux or non-windows operating systems as guests on Hyper-V, remove the default network adapter, add a legacy network adapter, configure the legacy adapter with a static MAC address.
I think that many organizations which are completely Microsoft shops might see a compelling value in consolidating with Hyper-V but those shop which use heterogeneous environments will need to more closely examine partial consolidation strategies or will end up executing a consolidation on a VMWare based virtualization platform. For essentially a public third version of the virtualization platform (2005, 2005 R2, 2008/Hyper-V), the offering has become more competitive and comprehensive however I look forward to the updates to the SCVMM products as well as the expansion of the Linux support that will make Hyper-V more competitive in the market.
Giving Hyper-V a Try
I think that any professional which works with virtualization needs to at least be in a position to have experience with the product. Definitely spend some time with the application. If you have a lab environment, with a few physical machines, install a Domain Controller. Install the Hyper-V box as part of the domain. Build a second Hyper-V box. Deploy the SCVMM 2008 into the environment. Grab the RC1 patch from Microsoft, and then work with the beta P2V and V2V capabilities. This is really the best way to get a feel for the feature set in an "enterprise" context as at that level you have the full set of features which offers the more competitive experience with what people look for from Xen and VMWare.
If you run into problems, there is a dedicated Hyper-V forum on the Windows Server 2008 portion of the TechNet forums. There is also another forum specifically dedicated to the SCVMM product which may be of more assistance with P2V, V2V, and host "clustering" issues on Hyper-V.