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.