The big news with the release of Microsoft Hyper-V Server 2008 R2 is Live Migration. Live Migration lets you move a Hyper-V guest from one clustered Hyper-V host to another clustered Hyper-V host while the guest is still running. This migration takes place usually within two seconds. The Clustered Shared Volumes (CSV) feature facilitates Live Migration in Hyper-V Server 2008 R2. CSV tracks which hosts are accessing which *.vhd files on the Storage Area Network (SAN), allowing multiple hosts to simultaneously access a given SAN LUN. But moving to Hyper-V isn't without its problems. The following issues are more of a heads up, rather than annoyances. Being aware of these potential pitfalls should simplify your transition to Hyper-V from the dedicated physical servers.
Hardware Requirements
Hyper-V uses a 64-bit hypervisor kernel. Your Hyper-V host must support hardware virtualization in both the CPU and BIOS. This includes the following generations of processors:
- AMD Athlon 64, revision D or later
- AMD Opteron, revision E or later
- AMD Turion 64, revision E or later
- AMD Sempron 64-bit capable version, revision D or later (experimental support)
- Intel EM64T VT-capable processor (experimental support)
Most middle- to high-end servers now support hardware virtualization. But, if you were planning to run Hyper-V on an older server, you'll probably need to purchase new hardware. Hardware virtualization support is usually disabled on the server when it comes from the manufacturer. Hardware virtualization support is enabled in the computer's BIOS settings, usually in the Advanced Settings section, and requires a hard reboot to make the setting active. Make sure you also enable the Execute Disable Bit (Intel) or NX Bit (AMD) in the BIOS in order to run Hyper-V.
Memory Requirements
Like being too rich or too thin, you can never have too much memory capacity on your Hyper-V host. I suggest purchasing a server that has at least 128GB of potential memory capacity. You might not initially install the maximum amount of memory in the Hyper-V host, but it's always good to have some breathing room. This is especially true if you plan to run Microsoft Exchange Server or Microsoft SQL Server on your Hyper-V host. Often you can increase the performance of disk-bound x64 Windows guests by allocating more memory to the guest for disk caching. I've found that a simple Exchange 2007 server with the roles of Mailbox, Client Access, Hub Transport, and Management Tools requires about 16GB of memory to avoid memory page swapping. Plan accordingly. With the current generation of servers that use DDR3 memory, purchase DIMMs in multiples of three in the same density for the best performance. Most of the Hyper-V hosts I configure start out with at least 24GB of memory if they're placed into a production environment.
Hyper-V and Server Core Installation
I strongly suggest installing Hyper-V on Server Core and not the full installation of Windows Server 2008 R2. Why? Security. Server Core has a significantly smaller footprint than the full version of Server 2008 R2 and requires significantly fewer patches. When you install Hyper-V on Server Core it does complicate the management of the Hyper-V host because you have to manage the Hyper-V host from another computer. More on this in the next section. You should place Hyper-V management computers on an isolated network that's separate from virtual server guest traffic. Consider placing a firewall between this Hyper-V management network and a secondary authentication device for the best security. It's important to protect the Hyper-V host because a compromise of the Hyper-V host will lead to really bad things—such as the ability to setup rogue virtual guests that can potentially hop from host to host in a clustered Hyper-V environment. It's difficult enough to find a compromised machine on your network, but if the compromised machine is virtualized, it's significantly more difficult to find.
Management Options for Hyper-V
Unfortunately, installing Hyper-V on Server Core complicates management of the Hyper-V host because it must be managed from another computer. Here are your management options when you install Hyper-V on Server Core:
Windows Server 2008 Hyper-V Tools feature. You can install the Hyper-V Manager on Server 2008 by going into the Server Manager, Features, Remote Server Administration Tools, Remote Administration Tools, Hyper-V Tools.
Windows Vista. You can download and install the Hyper-V Manager for Vista. You can download it for Vista x86 or Vista x64.
Windows 7. For Windows 7, you have to install and configure the Remote Server Administration Tools for Windows 7. The Remote Server Administration Tools run only on Enterprise, Professional, and Ultimate versions of Windows 7. After you install the tools, go into the Control Panel, Program and Features, Turn Windows Features On or Off, expand Remote Server Administration Tools, Role Administration Tools, Hyper-V Tools, and select the Hyper-V Management Tool.
System Center Virtual Machine Manager (VMM) 2008 R2. Although you can perform the basic management features with these tools, if you plan to place the Hyper-V host into a production environment, I strongly suggest you purchase VMM. It's roughly $870. It has the ability to store virtual machine (VM) templates in libraries, queue and troubleshoot live migrations, assign granular management roles, perform compatibility host checks for live migration and other features that you probably need (not want) for a Hyper-V production environment. VMM requires an X64 Server 2008 server. Although you can set up the server as a VM, the disaster recovery process will be simplified if this management server is installed on a physical machine. VMM also requires a version of SQL Server. You can use SQL Server Express Edition, but the database size is limited to 4GB. If you want to manage more than 150 Hyper-V hosts with the VMM, you'll probably need the full version of SQL Server 2005/2008, which doesn't have the 4GB database size limitation.
Live Migration and CPU compatibility. As I mentioned earlier, the big news with Hyper-V Server 2008 R2 is Live Migration. Live Migration allows you to move a virtual server guest from one Hyper-V host in a Hyper-V cluster without any downtime. I've seen the transfer of VMs from one host to another within one to two seconds. This allows you to perform Hyper-V host maintenance during the day without having to take down any virtual servers by moving all of the virtual server guests off of a Hyper-V host before taking it down. In an ideal environment, all the Hyper-V hosts in the cluster should be identical to guarantee the best Live Migration compatibility. There is no Live Migration between AMD and Intel Hyper-V hosts. Theoretically you can migrate virtual server guests among Hyper-V hosts that are in the same processor family, or you can enable processor compatibility mode to increase the compatibility between hosts for Live Migration. Although this matrix refers to VMware's VMotion, it gives you the general idea of what processor families are compatible for a Live Migration move. For more information on processor compatibility mode on Hyper-V refer to this Microsoft document. As you can see, it gets pretty complicated to determine Live Migration between hosts if the hosts are not identical. My suggestion is to keep it simple and keep all of your hosts in the cluster identical for the best Live Migration Compatibility.
Backup Options. For any production Hyper-V environment, I suggest obtaining *.vhd image backups of the virtual server guests. These image backups greatly simplify the disaster recovery process. You don't have to worry about reinstalling any applications in the virtual server guests. Some backup options even let you perform granular restores from the *.vhd images, although typically these backup images have to be stored on disk (not tape) in order to perform a granular restore. If you plan to use this method, make sure you have adequate disk space for your *.vhd images. Even though these backups are initially stored to disk, you should still eventually copy them to some type of offline media like tape. Some of the backup options available with Hyper-V are listed in this TechNet blog. If you've ever had to recover a DC, or a SQL Server or Exchange Server installation from scratch, you know that the process is stressful, complicated, and time consuming. If you have a backup of the *.vhd disk images for the failed server, you can simply restore these images and start the machine. If your *.vhd image backup does not contain the latest data backup, you might have to perform a data-only restore to your virtual server guest, but having the *.vhd images greatly simplifies the recovery process.
Physical to Virtual (P2V) server migrations. There are quite a few tools that allow you to migrate from a physical server to a virtual server. In general, these tools work fairly well, however the migrated machine will only be as stable as the original physical server. If the server has been in service for any length of time, I suggest you rebuild the server from scratch from a Hyper-V Virtual Server Guest template and just migrate the data. This is similar to the situation of upgrading a workstation from Vista to Windows 7. Most IT professionals agree that the migrated workstation will be more stable if you wipe the hard drive and perform a clean install of Windows 7, rather than performing an in-place upgrade. The same rules apply to a virtual environment, except the exposure is significantly greater because you're dealing with a server, not a workstation. However, I have performed P2V migrations successfully under the following conditions:
- The physical server had not been in service very long, and I could vouch for its stability.
- The software necessary to rebuild the physical server is not available and the physical server hardware is in danger of crashing because of its age.
If you have the luxury of building the server from scratch in a virtual environment, take the extra time to do so. The server will be more stable, and you'll have fewer problems in the future.
The Live Migration feature in Hyper-V Server 2008 R2 has positioned Hyper-V as a production-ready virtualization platform. As with any newer technology avoiding the pitfalls will ensure a successful Hyper-V implementation. I hope this article helps you avoid any potential annoyances.
Related Reading:
