Whether it is Horizon View, XenDesktop, or some other package, the implementation of a virtual desktop environment requires a significant time investment during the design phase. If care isn’t taken, the wrong design could be put into production, and the costs of fixing it could easily outweigh the benefits of implementing a virtual desktop solution.
So before we move into installing the actual components for a Horizon View environment, we’ll spend the next two posts on design considerations. This post, Part 3, will discuss design considerations for the Horizon View virtual desktops, and Part 4 will discuss design considerations for Active Directory.
Virtual desktop environments are all about the end user and what they need. So before you go shopping for storage arrays and servers, you need to start looking at your desktops.
There are three types of desktops in Horizon View 6:
- Full Clone Desktops – Each desktop is a full virtual machine deployed from a template and managed as an independent virtual machine.
- Linked Clone Desktop – A linked clone is a desktop that shares its virtual disks with a central replica desktop, and any changes are written to its own delta disk. Linked clones can be recomposed when the base template is updated or refreshed to a known good state at periodic intervals. This feature requires Horizon View Composer.
- Remote Desktop Session Host Pools – Horizon View has supported Windows Terminal Services for multiuser session support in a limited capacity. Horizon 6 has enhanced the RDSH features to include PCoIP support and application remoting. When RDSH desktops and/or application remoting are used, multiple users are logged into servers that host user sessions. This feature requires Windows Server 2008 R2 or Server 2012 R2 with the RDSH features enabled.
There are two desktop assignment types for desktop pools:
- Dedicated Assignment – users are assigned to a particular desktop during their first login, and they will be logged into this desktop on all subsequent logins.
- Floating Assignment – users are temporarily assigned to a desktop on each login. On logout, the desktop will be available for other users to log into. A user may not get the same desktop on each login.
Unless you have some overriding constraints or requirements imposed upon your virtual desktop project, the desktop design choices that you make will influence and/or drive your subsequent purchases. For instance, if you’re building virtual desktops to support CAD users, blade servers aren’t an option because high-end graphics cards will be needed, and if you want/need full clone desktops, you won’t invest in a storage array that doesn’t offer deduplication.
There are a couple of areas that need to be considered when designing the virtual desktops:
- Horizon View Configuration Maximums – There isn’t an official VMware document that outlines the official configuration maximums for a Horizon View environment. However, Ray Heffer has that information available on his blog.
- Applications – What applications are installed on the end-user desktops? Who uses them? Do any of the applications have any special hardware or licensing requirements? Are there any restrictions on who can access or use corporate applications or where they can be accessed from?
- Management Tools – What desktop management tools exist in the environment? The lack of a management tool to deploy applications like SCCM or Altiris will make it harder to manage full clone desktops.
- Physical Desktop Performance – When sizing out the virtual desktops that make up the desktop pools, it’s important to know how physical desktops are utilizing the resources they have. This is important for two reasons – it ensures that the virtual desktops are not being overprovisioned with CPU or RAM and that proper reservations and limits are set on the resource pools that the virtual desktops are assigned to.
- Company Culture – Are users granted admin rights and able to install their own software without asking IT? Are computers locked down and all applications white-listed? Or is it somewhere in the middle? Do users already have experience with remote solutions such as Microsoft RDSH desktops or Citrix? These are important considerations to keep in mind because environments where users have free run of their company computers may reject a centrally managed VDI environment or increase the workload for the IT staff, and staff who have no experience using Citrix or RDSH may have a hard time adjusting to their desktop being remote.
- Use Case – How are the virtual desktops going to be used? What problems are they going to solve for the business and the employees?
- User Profile Data – User specific session settings need to be preserved, especially if you are using non-persistent desktops or RDSH pools. Microsoft, VMware, and other partners like Liquidware Labs provide tools for profile management. If persistent desktops are deployed, user data may remain on the virtual machine, and a backup plan will need to be put in place to protect this data.
- Antivirus and Security – Users will be accessing the Internet from their virtual desktops, so they need to be secured from the myriad of threats out there. When selecting an antivirus solution for virtual desktops, you need to understand the impact that it will have on I/O when it updates and scans. You may also want to look at hypervisor-level security solutions using vShield Endpoint.
Once you have answers to these questions, you’ll be able to put together a design document with the following items:
- Number of linked clone base images and/or full clone templates
- Number and type of desktop pools
- Number of desktops per pool
- Number of Connection and Security Servers needed
If you’re following the methodology that VMware uses in their design exams, your desktop design document should provide you with your conceptual and logical designs.
Once you have a desktop design document, you’ll be able to start the infrastructure design. This phase would cover the physical hardware to run the virtual desktop environment, the network layer, storage fabric, and other infrastructure services such as antivirus.
The desktop design document will have a heavy influence on the decisions that are made when selecting components to implement Horizon View 6. The components that are selected need to support and enable the type of desktop environment that you want to run.
In part four, we will cover Active Directory design for Horizon View environments.
4 thoughts on “Horizon View 6.0 Part 3–Desktop Design Considerations”
This is a really good series on Horizon View – well done :-). I have one question however. I have perused many blogs, read books etc around View and Horizon, but none describe how one would say migrate from a legacy View 4.6 infrastructure to a new 5.3 or 6.0 infrastructure without doing in-place upgrades. Have you any tips on this and how one would run both in parallel and migrate the linked clones and golden images across to the new infrastructure?
I have this situation where the existing ESXi 4.1 and View 4.6 infrastructure is not suitable for other bad practice reasons (storage, hosts, compute etc) to do in-place upgrades. The endpoint Wyse devices P20 and P25′s seem eligible to support v5.3 🙂
That sounds like it is going to be a tricky upgrade.
You could make a clone of your original linked-clone golden images, upgrade the agent, and then rebuild your pools in the new environment. As long as you’re putting the desktops in the same OU so they get the same group policies, I don’t think there would be an issue.
With any upgrade or migration, the devil is in the details.
Thanks for the tips Sean. Much appreciated.
Rob (VCP – UK)
Pingback: Newsletter: August 10, 2014 | Notes from MWhite
Comments are closed.