The book lists best practices for physical servers hosting
Hyper-V roles, but perhaps there are more. This is your opportunity to help. Can you expand/edit these best practices or add more based on your experiences?
Determining the number of virtual machines that will be hosted on the Hyper-V server and the workloads they will be handling is critical. The version of the operating system that will be installed on the physical server can help in this regard, so the first
“best practice” is to consider using Windows Server 2008 Datacenter x64 with Hyper-V. The Datacenter x64 edition supports up to 64 processors, 2 terabytes of physical memory, and 16 failover cluster nodes for Quick Migration scenarios and allows unlimited
virtual machines to be run in Hyper-V. Selecting a Server Core installation provides added benefits, including enhanced security and lower maintenance.
For storage, consider using a storage area network (SAN) that is configured with highspeed (10,000 rpms or greater) drives (SATA or SAS) that support queued I/O and Raid 0 +1 configurations. You can use either Fibre Channel or iSCSI SAN hardware.
For networking, be sure to have more than one network card installed on the physical server and dedicate one network interface to Hyper-V server administration. This means no virtual networks in Hyper-V will be configured to use this NIC. For high-workload
virtual machines, you might want to dedicate a physical network adapter on the server to the virtual network the virtual machine is using. Ensure virtual machines that share a physical adapter do not oversubscribe to the physical network. Use the Reliability
And Performance Monitor to establish a performance baseline for the load and then adjust NIC configurations and loads accordingly.
If you have only a single NIC in the machine that you are configuring the Hyper-V role on and you are doing the configuration remotely (say, in an RDP session) if you choose to bind the Virtual Switch Protocol to the single NIC in the machine, you will be
disconnected from your session and a reconnection might not be possible until the newly created virtual network adapter has been properly configured.
Do not mix on the same physical server virtual machines that can take advantage of Hyper-V Integration Services with those that cannot. Virtual machines that cannot use Integration Services must use legacy network
adapters to gain access to the physical network. To accommodate legacy network adapters, you might need to disable some high-end features on the network interface, which can unnecessarily limit the functionality of the synthetic devices. Additionally, using
emulated devices places an extra workload on the Hyper-V server.
[Update 7/31/2012] After thoughtful discussion with original Hyper-V developers, it turns out that this particular recommendation does not make any sense. I prefer not to remove it silently since it is widely spread across the Internet
If you are running antivirus software on the physical server, you might want to consider excluding the Vmms.exe and Vmswp.exe processes. Also, exclude the directories that contain the virtual machine configuration files and virtual hard disks from active
scanning. An added benefit of using pass-through disks in your virtual machines is that you can use the antivirus software running on the physical server to protect that virtual machine.
Do not store any system files (Pagefile.sys) on drives dedicated to storing virtual machine data.
When running multiple high-workload virtual machines on a Hyper-V server, ensure a proper aggregate performance baseline is obtained over a specified period of time (say, five days during normal working hours) to ensure the hardware configuration for the
physical server is optimal to support the load being placed on it by the virtual machines. If adding more memory, processors, or higher performing storage is not possible, you might need to migrate the virtual machines to other Hyper-V servers.