About three month ago, I started a four part blog series on design considerations for a XenDesktop 7.1 implementation on Hyper-V 2012 R2. The blog series focused on networking and storage design decisions. I also covered design considerations for System Center Virtual Machine Manager and discussed some optimizations for improving Hyper-V performance.

Since that time I’ve received questions about topics that I did not cover in the blog series. I wanted to share some of the more common questions here since they pertain to design considerations for Hyper-V. Since publishing the previous blog series, Citrix has released XenDesktop 7.5 and XenApp 7.5. The previous blog series and this one are relevant to the new versions of both products.

Which edition of Hyper-V should I use?

XenApp and XenDesktop are supported on Hyper-V that is running as a role in Windows Server 2012 R2 Standard and Datacenter editions, or through the standalone hypervisor called Hyper-V Server 2012 R2. The decision on which version to use will largely depend on the flexcast model and the size of the environment. The standalone Hyper-V Server 2012 R2 is a server core installation with just the Hyper-V role enabled. It lacks a GUI, but in terms of performance and scalability there is no major difference between all three editions. The products do differ in the number of virtual server instances you are allowed to build before purchasing additional licenses:

  • Windows Server 2012 R2 Standard – 2
  • Windows Server 2012 R2 Datacenter – Unlimited
  • Hyper-V Server 2012 R2 – 0

There are also different licensing solutions available from Microsoft depending on different use case scenarios including:

  • VDI only
  • Hosted Shared only
  • A mix of VDI and Hosted Shared
  • VDI on thin client devices
  • BYOD and BYOCD

I strongly encourage you to visit Microsoft’s Licensing for Virtual Environments web page and speak to a Microsoft licensing specialist for guidance on the best selection for your environment.

Which type of installation should I perform on the Hyper-V host?

The server core installation offers more protection than the standard full installation. It has a smaller attack surface for viruses and other malware, and the operating system does not require patching as often as the full version. It also consumes less resources which is important when hosting a large number of virtual machines. The one drawback is that administration is performed from the command line. However for administrators that are not fully comfortable with command-line tools like PowerShell,  you can also manage the Hyper-V hosts remotely using the Hyper-V Manager or System Center Virtual Machine Manager Admin console.

Which processor type is recommended for Hyper-V Host?

Hyper-V requires a 64-bit Intel VT or AMD-V processor with Hardware Data Execution Protection (DEP) enabled. A Second Level Address Translation (SLAT) processor is recommended but not required. SLAT processors provide hardware assistance for memory virtualization, memory allocation, and address translation between the physical and virtual memory. This reduces memory overhead and allows a host server to run more virtual machines. (Note: If you plan to run the client Hyper-V on Windows 8/8.1, for demos or testing purposes, then a 64-bit SLAT processor is required.) The following TechNet page list different ways to check if a CPU is SLAT-capable.

If I have a host server, how can I determine total vCPU available for VMs?

For Hyper-V 2008 R2 Microsoft supports a ratio of 12:1 virtual processors per logical processors for desktops and 8:1 for servers. The following formula was used to determine total vCPU:

Total vCPU = (number of processors) * (number of cores) * (number of threads per core) * (12 or 8 depending on desktops or servers)

However, with Hyper-V 2012 R2, Microsoft states that the vCPU:pCPU ratios no longer apply and you can have as many vCPU as the hardware supports. With the higher scalability limits in Hyper-V 2012 R2, virtual RAM will more likely be the limiting factor than vCPU. However, understanding how many vCPUs are available is important when determining how many VMs per host to plan for. It is recommended that you know the operating system, application requirements, and workloads the VMs will be supporting in order to determine the most optimal physical to virtual ratio. Scalability testing is a great way to try different configurations for determining the number of VMs to place on a host for best performance. If the application requirements or workloads can’t be determined, or scalability tests can’t be performed, then the previous formula can be used to provide a rough estimate.

For VDI deployments is there any benefit to running 64-bit versions of Windows 8.1/7 over 32-bit versions on Hyper-V?

This will depend on your applications. A 64-bit OS will allow you to allocate more RAM per VM. A 32-bit Windows VM can only address up to 4GB of RAM. Most VDI deployments running a standard or light workload will typically only require about 2 – 4GB of RAM. You should also consider if application compatibility is required for legacy 16-bit applications and 64-bit driver support for peripherals. My colleague Andy Baker wrote an excellent blog on the subject that I encourage you to read.

If the VMs will be using dynamic memory it is worth noting that Hyper-V 2012 R2 by default will set the max value to 1TB, even if the host does not have that much RAM installed. The guest VM however can only use the maximum amount of RAM supported by the OS. Windows 8.1 Pro x64 supports up to 512GB of RAM. So be sure to change the max value to a reasonable setting that will not impact other running VMs on the host should an application becomes faulty or leaks.

For the System Center Virtual Machine Manager database which SQL HA option is recommended?

Microsoft recommends as a best practice either: AlwaysOn Failover Clustering  or AlwaysOn Availability Groups. The differences between the two solutions are highlighted in the following table:

AlwaysOn Failover Clustering AlwaysOn Availability Groups
Where does HA occur? At the server level At the database level
Requires Windows Failover Cluster service Yes Yes
Edition of SQL Server required Standard (2-node maximum) or Enterprise Enterprise
Shared storage required Yes No

AlwaysOn Failover Clustering is recommended for data protection through a third-party disk solution (SAN), and AlwaysOn Availability Groups is recommended for data protection through SQL Server. Please refer to High Availability Solutions (SQL Server) for specifics on each solution. Database mirroring and log shipping are also supported, however Microsoft is planning to remove mirroring from a future release of SQL Server. Mirroring is the recommended solution for the other databases used by Citrix components, however SQL clustering and AlwaysOn Availability Groups are supported as well.

Is it necessary to run anti-virus software at the guest level if I have it running on the Hyper-V host?

Most anti-virus scanners (AV) running on the host are configured to exclude the VHDX/VHD files from scans so as to not affect the performance of the VMs. One argument I often hear against placing AV agents on pooled desktops is that if the desktop becomes infected it is easy to fix by simply rebooting it. Since no persistent data is saved, why pay for the extra desktop AV licenses. Even so, you should always consider installing an AV solution on pooled desktops. While pooled desktops are not susceptible to boot viruses (assuming the master image is clean), they are still at risk to viruses downloaded from the Internet through email attachments, web browsers or other means.  An AV agent should be installed to detect the virus so appropriate action can be taken immediately. Dedicated desktops and infrastructure servers should be treated the same as any physical computer on the network when it comes to an AV solution. For the Citrix Guidelines on AV software configuration please see CTX127030.

How should I backup my Hyper-V host?

You can perform backups at the host level or at the guest VM level. Performing the backup at the host level is easier because it captures more data than backing up individual VMs, including the VM configuration and associated snapshots. Regardless of the backup method selected, ensure that the backup software is designed to work with Hyper-V, failover clusters, and cluster shared volumes or you may encounter serious pain points when trying to perform a restore/recovery. Many backup solutions will backup to disk, so make sure there is sufficient storage to support all VHDX/VHD files on the local or shared storage.

That’s it for now. If you have any additional questions or comments regarding XenDesktop or XenApp on Hyper-V please add them to the comments section. Please let me know what other topics you would like to see covered as well.

Ed Duncan – Sr. Consultant
Worldwide Consulting
Desktop & Apps Team
Virtual Desktop Handbook
Project Accelerator