eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Windows Server 2008 R2 is a modest upgrade, but it’s one that’s worth paying attention to for organizations tracking Microsoft’s foray into server virtualization–Hyper-V–as well as for companies looking to deploy Windows 7 in the short term.
With this R2 release, Hyper-V gains the capacity for shifting virtual machines from one host to another without interruption, a feature Microsoft calls Live Migration. Live Migration is an important addition, but Hyper-V has plenty of catching up to do with the better-established virtualization lineup from VMware, which has included support for migrating running VMs since 2003.
For images of Windows Server 2008 R2 in action, click here.
In particular, I find VMware’s ESX Server simpler to configure and use than Hyper-V, both when manipulating a lone virtualization host and when controlling clusters of hosts. However, in the latter case, I’ve yet to try Microsoft’s forthcoming Virtual Machine Manager product, which should smooth multi-host management.
Shipping in tandem with Windows 7, Server 2008 R2 is the first Windows server release to hit the market alongside a new Windows client in nearly 10 years. Microsoft has outfitted R2 with a handful of so called “better together” features intended to grease the upgrade skids for the pair of OSes.
These new capabilities include a means for providing Windows 7 clients with secure, VPN-less access to company networks via DirectAccess; with faster connections to file shares through BranchCache; and with enhancements to Terminal Services (now called Remote Desktop Services) sessions. eWEEK Labs will examine the Server 2008 R2/Windows 7 combo more closely in the near future.
Beyond the Hyper-V and Windows 7-related changes, R2 includes an assortment of smaller enhancements centered around managing remote systems, scripting administrative tasks via PowerShell, and reducing power consumption on physical and virtual machines running the OS.
Microsoft has not yet announced pricing details for Windows Server 2008 R2, but I expect that pricing will be similar to Windows Server 2008, which is available in five versions: a $999 Standard edition that comes with five CALs (client access licenses); a $3,999, 25-CAL Enterprise Edition; a $2,999-per-processor Datacenter Edition; a $2,999-per-processor version for Itanium-based systems; and a $469 Web server edition.
The changes that Microsoft has announced include the removal of all Windows Server 2008 SKUs shipping without Hyper-V, along with a CAL change in which Windows Server instances running only the Hyper-V role will not require Server 2008-specific CALs. What’s more, Microsoft will be selling a new, Foundation Server SKU that will be bundled with OEM servers and is intended for small businesses with fewer than 15 users.
Starting with Windows Server 2008 R2, Microsoft is dropping support for the x86 platform while maintaining x86-64 and Intel Itanium 2 processor platform support.
I tested the x86-64 version of Windows Server 2008 R2 Datacenter Edition on a pair of HP servers–a DL360 G6 and a DL380 G6, which I used as Hyper-V nodes in a Failover Cluster configuration. I also tested R2 systems running domain controller and remote desktop services roles in virtual machines hosted from my Hyper-V pair.
Hyper-V Live Migration
One of the most important new features in Windows Server 2008 R2 is support for live migration of virtual machines in the product’s Hyper-V virtualization role. Live migration enables running virtual machines to shift from one node to another without interrupting the applications running on the VM. The previous version of Hyper-V offered Quick Migration, which involves a short period of downtime during the migration.
Hyper-V taps the new Cluster Shared Volumes feature within Windows Server’s Failover Clustering role to accomplish Live Migration. The Cluster Shared Volumes feature compensates for the fact that Windows’ NTFS is not a clustering file system by supplementing NTFS with an additional layer of logic that keeps track of which VM “owns” a given shared storage LUN at a particular time.
On the positive side, Microsoft’s use of NTFS for Cluster Shared Volumes keeps the volumes more broadly accessible than they might otherwise be. Full access to VMware’s VMFS, for instance, is only available to VMware’s own products.
The downside of this approach is that Microsoft’s Cluster Shared Volumes work with a narrower range of storage hardware than do VMware’s VMFS volumes.
Specifically, Microsoft’s Cluster Shared Volumes require storage systems with support for persistent reservations. In my tests, this meant that I could not use the same Linux-based OpenFiler iSCSI storage appliance that we typically use with VMware testing to evaluate Cluster Shared Volumes. I opted instead for the OpenSolaris-based NexentaStor storage appliance, which, when used with Sun’s new COMSTAR storage subsystem enabled, delivered the persistent reservation support that Cluster Shared Volumes requires.
Once I’d sorted out my shared storage issues, I had to smooth out an additional wrinkle regarding the Windows Server 2003 Active Directory domain in our test lab.
We’d configured the domain to use the backward-compatible mixed mode functional level to which Server 2003 defaults. Our two Hyper-V host machines sported machine names of more than 16 characters, which appeared to lead to intermittent network access problems. It wasn’t until I truncated the machine names to 16 characters that everything worked as expected.
In the cases of both the shared storage and the directory issues I experienced, the Failover Clustering role’s validation wizard helped point to the errors-to varying degrees. With regard to storage, the wizard told me exactly what I needed to do. However, with the directory issues, the wizard pointed vaguely to problems confirming that my nodes lived in the same organizational unit. I had to sort out the exact issue through trial and error.
After everything was set up, I was able to migrate running VMs from one Hyper-V node to another with very little noticeable downtime.
I tested the seamlessness of Live Migration by creating an R2 virtual machine running the Remote Desktop Services role. I configured my RDS instance to serve up Word 2010 as a RemoteApp and opened up Word on a Windows 7 system on my network. After starting a new Word document and beginning to type, I kicked off a Live Migration operation through R2’s Failover Clustering management console and switched back to my document. During the migration, I noticed a momentary hiccup in the responsiveness of my remote Word session, but none of what I was typing was lost.
Live Migration was very easy to use, but I found the process of configuring and using Live Migration in Windows Server 2008 R2 significantly more complicated than with VMware ESX server and VirtualCenter. In contrast to VMware’s product, where all tasks are gathered together in a purpose-built interface, the tasks required to configure Cluster Shared Volumes in Windows Server involve visits to various existing and new Windows utilities.
Executive Editor Jason Brooks can be reached at [email protected].