The hypervisor itself doesn't require much in terms of hardware. It shares an official requirements list with the full Windows Server 2012 product, which is as follows:

Hyper-V's requirements extend beyond these to the following:

While not required for the Server edition of Hyper-V unless you intend to use RemoteFX, second-level address translation (SLAT) can greatly enhance the performance of memory-intensive virtualized workloads. The various features of RemoteFX have required and recommended features of their own (one of which is SLAT), so if VDI is part of your plan, ensure that the hardware you purchase supports those.

These are the minimum requirements to install Hyper-V Server. If you use only these minimum requirements, you will not have enough resources to be able to virtualize any load. The following sections will discuss how you can appropriately size your hardware.

There is no one-to-one matching of the virtual CPUs (vCPUs) inside virtual machines to the physical CPUs of the hosts. When a processing thread is created inside a virtual machine, Hyper-V Server sends it to the next open CPU core, usually without any concern over which actual CPU it is sent to. The number of vCPUs assigned to a virtual machine limit how many active processing threads it can have at any given time, not which physical CPUs it has access to. This means that there's no simple way to map existing CPU requirements in a physical system to what it will need when moved to a virtual environment. A concept diagram follows:

In the previous diagram, threads are numbered in the order in which they were started. Note that the image shows a simplified view of what actually occurs in order to help you to understand the concept. Actual thread scheduling is somewhat more complicated than the indicated round-robin style.

Microsoft indicates that a single physical core can support eight vCPUs for legacy operating systems and twelve for Windows Server 2008 R2 and later server operating systems or Windows 7 and later desktop operating systems. However, the actual supportable load is primarily determined by how much CPU processing time a virtual machine calls upon multiplied by the number of threads it activates. Make sure that the CPUs you select for your hosts can support the load you will be placing upon them. If you're uncertain on how to proceed, core count is usually more important than core speed in a virtualization environment. Since you're building a cluster, adding hosts may be preferable to choosing more expensive systems with more CPU sockets or cores. If you will be using virtual machines with many vCPUs, it is recommended that you read Chapter 7, Memory Planning and Management, so you understand NUMA before sizing your host.

Memory is not a scheduled, shared resource like CPUs. Whatever memory Hyper-V Server assigns to a virtual machine at any given time is completely dedicated to that machine until Hyper-V Server takes it away. Dynamic Memory can be employed in some cases to allow virtual machines to request and release memory to the hypervisor as their needs change. This does not change the non-shared nature of memory. The following image is a visualization of memory allocation:

As with CPU, you may reach a point where it makes more sense to scale out than to attempt to increase the amount of physical memory in a single host computer. Another option is to plan to reduce the amount of memory allocated to virtual machines. In many cases, the amount of memory installed in single-use physical computers is more, sometimes dramatically more, than is actually necessary. Because it's rather simple to allocate more physical memory to a virtual machine, you can plan to start small and add additional RAM if virtual machines appear to need it.

As you size your physical RAM to the anticipated load, remember that Windows, like other modern operating systems, can work with less physical RAM than is actually needed. If a virtual machine doesn't have enough RAM, it will begin the process of paging—using the hard drive as a stand-in for memory. Some paging is expected and is almost unavoidable, but enough of it will cause a noticeable drag on system performance. Also, even if a guest has sufficient RAM for all services, its operating system will try to maintain a comfortable amount of free RAM and may initiate paging when it is not strictly necessary. Since access to disk is, like CPU, a resource that must be scheduled among virtual machines, heavy disk access is something to be avoided when possible. Take care in the way that you allocate memory.

One thing about Hyper-V Server that distinguishes it from other hypervisors is that, with the exception of guest startup, it never pages the memory assigned to a virtual machine. Any paging involving a guest is initiated and controlled by that guest and utilizes a page file created and managed by that guest. The management operating system will provide paging for its own processes as any other operating system would. The following image shows how page files are placed for the hypervisor and its guests:

The management operating system will function well down to about 512 megabytes of available RAM if it provides no other service than Hyper-V Server. It is recommended to leave one gigabyte or more for the management operating system. This number increases as the number of virtual machines increases. Refer to Chapter 7, Memory Planning and Management, for a more thorough discussion on precise memory allocation.

Networking will be more fully examined in the next section. Please review that before completing your hardware specifications for host computers. Members of Hyper-V Server clusters typically have substantially greater networking requirements than other Windows Server deployment types.

In a cluster environment, the storage that you'll spend the most time on will be the shared storage, not the host storage. However, host storage must still be planned for because that is the location that Hyper-V Server will run from. You have two options. One is to use internal hard drives. The other is to use a USB flash drive. Either option is perfectly viable for a basic installation. The farther you intend to deviate from a basic installation, the more sense it makes to utilize traditional internal drives.

The two primary reasons to use USB flash drives are expense and ease of system replacement. A flash drive needs to have at least thirty-two gigabytes of capacity in order to satisfy the minimum requirement for Hyper-V Server 2012. The cost for a drive of that size is practically negligible in comparison to the rest of the hardware required for a project of this type. They can be kept in quantities and rapidly duplicated for easy replacement in the event of a failure. However, the most current systems commonly available both in terms of the host bus and in flash drives are still USB 2.0. They have adequate performance for a Hyper-V Server system that will store its virtual machines elsewhere, but if you will require anything else to be installed on the system, then they may prove to be insufficient.

If you choose to use internal disks, you have a choice between traditional spinning disks and solid-state storage. For the most part, the management operating system and hypervisor will not benefit substantially from the speed offered by a solid-state system, so spinning disks is the most common option. It is recommended that you configure these drives in a mirror (RAID 1).

Even though Hyper-V Server requires little in the way of configuration and can be replaced fairly quickly, this is a very simple way to implement basic redundancy and fault tolerance with a minimal investment. Also, you may choose to run some software inside the management operating system and you may even find cause to place some virtual machines on internal storage. Each additional burden you place on the management operating system beyond hypervisor installation increases the benefits you can gain from using spinning disks and building in a failsafe.

Even though you've already decided on Hyper-V Server for your hypervisor, there is more than one way to gain access to its technologies. The two major options you have are to use Hyper-V Server 2012 or Windows Server 2012 with Hyper-V as a role. In all cases, Hyper-V is the hypervisor. You are deciding what to use as the management operating system. That term will be explored in more detail in the next chapter.