Hardware requirements

In this section of Hyper-V prerequisites, we will go through the hardware requirements; and some of these requirements are hardcore requirements, meaning you have to have these elements available before you start virtualizing your workload on Hyper-V.

Processor

The difference between the earlier Microsoft virtualization products and Hyper-V is mainly the processor requirements: where the earlier Microsoft virtualization products, such as Virtual PC and Virtual Server, could run on the 32-bit operating system, Hyper-V only works with 64-bit compatible processor hardware. Along with the 64-bit processor available, there are two other elements that are required by Hyper-V in order for the processor to operate; they are as follows:

• Hardware-assisted virtualization: The processors that support hardware-assisted virtualization provide an additional privilege mode above Ring 0 (referred to as Ring -1) in which the hypervisor can operate, essentially leaving Ring 0 available for guest operating systems to run. In the market, each processor maker has given different names to its own hardware-assisted virtualization platform, for example, Intel calls it VT, and AMD uses the term AMD-V for it.

• Hardware-based Data Execution Prevention: The second requirement of Hyper-V from the processor side is Data Executive Prevention. Hardware-based ata Execution Prevention ( DEP) allows the processor to mark sections of memory as nonexecutable. This feature is available in processors with AMD NX and Intel XD support.

We can summarize the processor requirements as follows:

• The following are the requirements when working with an Intel processor:

  • x64 processor architecture

  • Support for Execute Disabled Bit

  • Intel® VT hardware virtualization

• The following are the AMD processor's requirements:

  • x64 processor architecture

  • Support for Execute Disable Bit

  • AMD-V® hardware virtualization

Storage

All those storage designs that are supported and workable with Microsoft Windows Server for a particular operating system version are applicable for Hyper-V. But there is a catch—since usage of disk storage changes when it comes to Hyper-V, there are some recommendations that you should consider before you plan and buy hardware for your Hyper-V server.

There will be multiple concurrent sessions on the storage—where a number of virtual machines' virtual storage (VHD, VHDX) will be located—so disk storage with fewer disk spindles will provide poor disk I/O, which will eventually cause poor virtual machine performance. So it is always recommended to use storage with more disk spindles for Hyper-V, which provides better disk I/O, and thus better virtual machine performance.

Let me elaborate this: having more disk spindles means that on your storage side, either your local server storage or SAN storage, you would have more than one disk, and based on your performance and failover requirements you might want to choose an appropriate RAID model for this. So, in this type of setup, more disks would be added to your storage pool and the disk I/O for read/write would be spread across all these disks, which will provide a better resiliency and performance.

Disk types

The type of hard drive added to the host server or to the storage array for the host server, should have significant impact on the overall storage performance. The differential performance factor for the hard disks is the interface architecture (for example, U320 SCSI, SAS, or SATA). The two elements, which are the rotational speed of a hard disk (7200, 10k, or 15k RPM) and the average latency in milliseconds, play a vital part in the overall performance and availability of storage for a hypervisor server. Additional factors, such as the hard disk cache and the support for advanced features, for example, Native Command Queuing (NCQ), can also be considered as performance improvement factors.

For sound storage planning of the hypervisor and virtual machines, there are a few important elements that should always be carefully evaluated before choosing the right storage for your virtualization stack. These elements are the type of storage, storage IOPs, accepted storage latency, and of course storage size. Mostly, for the virtual machine, storage performance is not the first requirement but the storage size is. From a practical standpoint, I have seen many small, medium, and even large organizations where the hypervisor server has a good number of processors and a large RAM, but due to the unavailability of storage these hardware boxes remain underutilized. Therefore, it is always recommended to go for a bigger size of hard disk instead of finding an expensive one for good performance. Not all the virtual machines need to be placed on a high-speed disk; their OS virtual hard disk (VHD/VHDX) can be placed on a high-speed SATA, and their page file or application/data VHD/VHDX can be placed on a high-speed disk. Utilizing 15k RPM drives instead of 10k RPM drives can result in up to 35 percent more IOPS per drive.

Use the information given next to evaluate the cost/performance tradeoffs.

SATA disks

SATA could be your first choice when considering the Hyper-V storage. Among all other storage types, SATA is the cheapest option, and provides average read/write speed for the data. It is always recommended to go for a higher speed disk if your intended data or workload needs higher performance. SATA disks primarily come with the speed of 1.5 GB/s and 3.0 GB/s.

SAS disks

SAS disks are the next fastest type of disks. If you want fast disks for your highly touched data or accessed virtual machine, then SAS disks would be a standard choice. These disks provide faster I/O response from the read/write activities. Usually, SAS disks come with the rotational speed of 10k to 15k with an average latency speed of 2 to 3 milliseconds.

Fibre Channel disks

Fibre Channel disks perform in a similar way to SAS disks, but have a different interface for connectivity. Since they contain the word "Fibre", their connectivity medium is a fiber cable, which usually connects to the server HBA card on one end, and to the SAN switch on the other. Fibre Channel disks come in both variations of 10k and 15k RPM.

Tip

Recommendation

Instead of going to SATA disk, I would recommend going for SAS 15k RPM to 10k RPM disk, which provides better performance.

All of the previously specified storages can be used in the following ways for Hyper-V virtual workloads:

• Pass-through disk

• Fixed disk

• Dynamic disk

• Differential disk

We will discuss all of the preceding storage types in more detail in Chapter 6, Insight into Hyper-V Storage.

Memory

When it comes to memory planning, it is always recommended to go for server hardware that provides enough memory expansion and may accommodate your future memory needs. The Dynamic Memory Optimization feature of Windows Server 2008 R2 SP1 took Hyper-V to a new era, where Hyper-V changed the face of how Hyper-V memory assignment was done in VM workloads as compared to how it was done in the legacy Hyper-V versions. Dynamic memory gave a new way for administrators to set dynamic thresholds for VM workloads to start from an initial memory assignment and burst to a certain limit. It is always recommended to go for a larger number of filled memory slot banks for the Hyper-V boxes, because when it comes to the Hyper-V server memory planning, RAM legacy and speed is not much more important than the size. In addition to this, we should also pay attention while buying the server hardware for the Hyper-V role; we should focus on the server boxes that support more memory in terms of quantity, because this is your one-time investment, and buying a server with less support for RAM may end up with your investment having less ROI.

Networking

This is another crucial part: while considering hardware components for Hyper-V implementation, as we discussed previously, disk storage with more spindles is preferred. Due to high I/O utilization, it may provide better and fast response. In the preferred networking selection for Hyper-V, similar recommendations come to those that we saw for storage, where it is recommended to have multiple NICs available to the Hyper-V host.

Here we will see an example. We have an HY-SVR-0001 server, which has one NIC card with 1 Gbps of speed, installed on it. After installing Hyper-V role, we select this NIC and create an external virtual network on Hyper-V from the network manager. Now, this physical NIC is being used for all the virtual machines created on this server. In the initial days, when fewer virtual machines used to be created on Hyper-V, network performance while accessing virtual machines didn't suffer. But with the passage of time, and increasing demand for virtualization and support from the vendors and applications, more virtual machines are being created as compared to earlier. This increasing number of virtual machines need more bandwidth and better network planning for the Hyper-V role. After finding the root cause, the administrator found that the same physical NIC was being used for all the VMs, and on top of it the file server virtual machine's backup along with all virtual machines' backups were also configured on the same physical NIC.

Hence, it is highly recommended to carefully plan your Hyper-V physical network connectivity to the server farm. Depending on your Hyper-V server configuration, you may need to have more than one network configured, among the following network options:

• Cluster private network

• Live migration network

• Hyper-V replica traffic network

• Hyper-V management network

• iSCSI SAN connectivity network

As you can see in the example that we discussed previously, there is plenty of network traffic that our Hyper-V server will be part of; therefore, it is highly recommended to have multiple NICs available in your Hyper-V server so that it can individually cater to these different patterns of traffic. In addition to this, it would also be necessary for you to have teamed Hyper-V NICs for the client connectivity network, where the hosted application or VM may require more bandwidth due to the number of concurrent network connections from the client side.