Designing a Non-Clustered Hyper-V Host
I’m going to bring things back a bit to discuss a topic that many, including myself, take for granted. I tend to forget that not everyone has been working with Hyper-V since 2008, and I’m initially surprised when someone asks me how to design a standalone Hyper-V host. Questions such as “How much disk do I need?” and “How much RAM do I need?” quickly indicate that not only are these people new to Hyper-V, but they’re new to virtualization. So let’s get back to basics and discuss how to design a standalone Hyper-V host (AKA non-clustered host).
(Editor’s note: Be sure to check out these related articles as well: Basic Hyper-V Replica Configuration Between Non-Clustered Hosts and Preparing Host Clusters For Hyper-V Replica )
Standalone Hyper-V Host: How Much Disk Do You Need?
We can divide resources such as RAM and storage into two groups:
- The needs of the host for the management OS (what is incorrectly referred to as the “host OS”) that runs in the parent partition.
- The requirements for the virtual machines.
The Management OS
The management OS needs as much disk as you see fit for a basic installation of Windows Server 2012 (WS2012) or Windows Server 2012 R2 (WS2012 R2). Bear in mind that a Server Core (without the GUI) installation or a Hyper-V Server installation will consume slightly less disk space.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
(On a tangent: I’ll care about the couple of GBs saved by a Server Core installation on the host when I can purchase disks of less than 100 GB for servers… some time back in 2001!)
I’m typically conservative and will allow 60 GB of space for the management OS. But we can’t get disks that small anymore, unless you are booting from SAN, and you’re not going to do that with non-clustered hosts. So I’ll have a pair of disks in a RAID1 configuration for the management OS.
Hyper-V doesn’t need the management OS to have great performance. There is no second-level paging in Hyper-V (where the host uses a paging file on disk to blindly provide slow virtual RAM to VMs that have been promised memory that doesn’t exist). So if I have the option from the manufacturer, I’ll be happy to put in slow SATA disks into this RAID1 LUN for the host.
The virtual machines are going to need, well, as much disk space as they need. If a VM needs 300 GB disk space, then it needs 300 GB disk space. There are other considerations:
- Save state: If you use the option to save a VM’s state when the host shuts down then Hyper-V will maintain a BIN file for the VM that matches the VMs amount of assigned memory. This is replaced by a VSV file of the VM’s state when it was saved.
- Smart paging: If you are overly aggressive with the use of the minimum RAM setting in Dynamic Memory, and the host is at RAM capacity when it reboots or a number of VMs reboot, then Hyper-V must temporarily use a file in the VM’s storage location to simulate RAM. This file disappears when the VM returns to the previous idle state and balloons back down to its minimum memory amount.
- VSS snapshots: Free space is required on the physical LUN where VMs are stored in order to perform a Volume Shadow Copy Service (VSS) snapshot for an application consistent backup of the VMs.
- Good practice: It is good practice to have some free space, especially if you are going to use dynamically expanding virtual hard disks.
Sum up the amount of storage you need, and that’s what you need to allocate to the VMs.
In a simple design, a second LUN (the D: drive in the management OS) is created in the server. Use fast storage – this means 15K disks with a RAID10 configuration. RAID5 is more space efficient but the rule of thumb for RAID5 is that you lose 75 percent of your write performance. Would you store database log files on RAID5? If so, then you should read this.
A simple storage design for non-clustered hosts
An alternative is to use SMB 3.0 storage to store the VMs. This means that you don’t have a D: drive on the host. Instead you store the VMs on WS2012 or WS2012 R2 file shares. This means you can get the same live migration that a clustered host would have.
Note: If you are implementing WS2012 R2 Hyper-V for VDI (and VDI only) then you can enable disk deduplication. This will greatly reduce disk space utilization. Contrary to your initial reaction, WS2012 R2 deduplication increases storage performance of the VDI VMs.
How Much RAM Do You Need?
Allow anything from 1.5 GB to 5 GB of RAM for the management OS depending on what levels of management you will have running on the host. Some tools require more RAM than others.
VMs will also have a requirement. Once again, you have to sum up the requirements of your individual VMs. If you won’t use Dynamic Memory then that’s easy. If you will use Dynamic Memory, then you need to size for peak usage.
You can do this the easy way with less functionality, and you can do this the more interesting way with more functionality.
This is easy enough. You will need four NICs.
- NICs 1 and 2: Team the NICs, configure a single IP address, and use this team to manage the host.
- NICs 3 and 4: Create a second NIC team, and do not assign it an address. Instead, create a virtual switch that is connected to the team interface, and use this team just for virtual machines.
Simple networking in a non-clustered host
This is where you want to start designing your networking for things such as:
- Hyper-V network virtualization: Standalone hosts are a very popular option for hosting companies because of the higher VM-to-host (earning-to-investment) ratio than clusters can offer.
- Live migration: Non-clustered hosts can use shared-nothing live migration (with no SMB or SAN storage) and live migration with SMB 3.0 storage.
- Storage: Additional networks are required for iSCSI or SMB 3.0 storage. Note that WS2012 R2 can make great use of SMB 3.0 networks for SMB-powered Live Migration.
- Backup: Do you need a dedicated backup network to avoid interruptions to management operations?
You should read more on the concepts of converged networking if you want to use more complex network designs with Hyper-V hosts.