Hyper-V 101: What Windows Server Media Should I Use?

This may seem like a bit of a silly N00b style post but there’s a good reason for it.

How many of us are using Windows Server Media to install hosts via USB Flash then guests via ISO?

I venture to guess almost all of us.

Okay, POLL Time: What is the _date stamp_ on the Setup.EXE located on that flash/ISO?

As of today, if it’s a date earlier than November 22, 2014 then it’s _too old_ to be used in production systems:

Please log on to the Microsoft Volume Licensing Service Centre, MSDN, or TechNet to download a newer ISO.

Then update the flash drives used to install Hyper-V hosts and nodes.

It should be Standard Order of Procedure (SOP) to keep operating system load souces up to date.

Philip Elder
Microsoft High Availability MVP
MPECS Inc.
Co-Author: SBS 2008 Blueprint Book

Hyper-V Virtualization 101: Some Basics Around Hyper-V Setups

Here are some pearls learned over our years working with Hyper-V:

• Host/Node Setup
• Make sure the host and all nodes in a cluster have the BIOS Settings identical (All settings)
• Leave ~1GB to 1.5GB physical RAM to the host
• We leave 1.5GB of space on a dedicated to VM LUN
• We leave ~50GB to ~100GB of free space on a shared LUN/Partition
• We set the MiniDump option and lock the swap file down to 840MB
• wmic RECOVEROS set DebugInfoType = 3
• Always set up a standalone host with two partitions: OS and Data
• Hyper-V
• Hyper-V lays out a file equivalent in size to the vRAM assigned to VMs. We must have space for them.
• Snapshots/CheckPoints create differencing disks. These _grow_ over time.
• Deleting Snapshots/CheckPoints requires enough free space to create an entirely new Parent VHDX.
• vRAM assigned to the VM should not traverse NUMA nodes (performance) (more on hardware).
• vCPUs = Threads in CPU and must be processed in parallel thus # physical cores - 1 is best.
• GHz is preferred over CPU Core counts for most workloads.
• Storage
• Be aware of the IOPS required to run _all_ workloads on the host/nodes.
• More smaller sized spindles is better than less larger size spindles = More IOPS.
• 10GbE should be the minimum bandwidth considered for any iSCSI deployments.
• At least _two_ 10GbE switches are mandatory for the storage path
• Networking
• Broadcom physical NIC ports must always have VMQ turned off (blog post)
• We prefer to use Intel Gigabit and 10Gb Ethernet Server Adapters
• We start with a minumum of 4 physical ports in our hosts/nodes
• UPS Systems
• UPS Systems should have at least 1-1.5 Hours of runtime.
• Host/Nodes and storage should be tested for shutdown durations.

There are quite a lot of these types of posts on our blog. Please click through the category tags to find more!

Thanks for reading.

Philip Elder
Microsoft High Availability MVP
MPECS Inc.
Co-Author: SBS 2008 Blueprint Book

Hyper-V Virtualization 101: Hardware Considerations

When we deploy a Hyper-V virtualization solution we look at:

1. VM IOPS Requirements
2. VM vRAM Requirements
3. VM vCPU Requirements

In that order.

Disk Subsystem

The disk subsystem tends to be the first bottleneck.
For a solution with dual E5-2600 series CPUs and 128GB of RAM requiring 16 VMs or thereabouts we'd be at 16 to 24 10K SAS drives at the minimum for this setup with a 1GB hardware RAID controller (non-volatile or battery backed cache).
RAID 6 is our go-to for array configuration.
Depending on workloads one can look at Intel's DC S3500 series SSDs or the higher endurance DC S3700 series models to get more IOPS out of the disk subsystem.

RAM

Keep in mind that the physical RAM is split between the two processors so one needs to be mindful of how the vRAM is divvied up between the VMs.
Too much vRAM on one or two VMs can cause the physical RAM to be juggled between the two physical CPUs (NUMA).
Note that each VM’s vRAM gets a file written to disk. So, if we are allocating 125GB of vRAM to the VMs there will be 125GB of files on disk.

CPU

And finally, each vCPU within a VM represents a thread to the physical CPU. For VMs with multiple vCPUs every thread (vCPU) for that VM needs to be processed by the CPU's pipeline in parallel. So, the more vCPUs we assign to a VM the more the CPU's logic needs to juggle the threads to have them processed.
The end result? More vCPUs is not always better.
I have an Experts Exchange article on Some Hyper-V Hardware and Software Best Practices that should be of some assistance too. In it I speak about the need to tweak the BIOS settings on the server, hardware configurations to eliminate single point of failures (SPFs), and more.

Conclusion

In the end, it is up to us to make sure we test out our configurations before we deploy them. Having a high five figure SAN installed to solve certain performance “issues” only to find out they exist _after_ the fact can be a very bad place to be in.
We test all aspects of a standalone and clustered system to discover its strengths and weaknesses. While this can be a very expensive policy, to date we’ve not had one performance issue with our deployments.
Our testing can also be quite beneficial to present an IOPS and throughput reports based on sixteen different allocation sizes (hardware and software) to our client _and_ the vendor complaining about our system. ;)
Philip Elder
Microsoft Cluster MVP
MPECS Inc.
Co-Author: SBS 2008 Blueprint Book