Difference between revisions of "Virtual Desktop Design Considerations"

From vmWIKI
Jump to: navigation, search
(Created page with "== Originating Authors == Mike Laverick File:Mike@vmware-MEDIUM.png‎ [https://twitter.com/VirtualisedReal Barry Coombs] [[File:Screen_Shot_2014...")
(Originating Authors)
Line 1: Line 1:
== Originating Authors ==
== Originating Author ==
[[User:Mike_laverick|Mike Laverick]]
[[User:Michelle_Laverick|Michelle Laverick]]
[[File:Michelle Laverick.jpg|310px]]
[https://twitter.com/VirtualisedReal Barry Coombs]
[https://twitter.com/VirtualisedReal Barry Coombs]

Latest revision as of 05:56, 13 February 2018

Originating Author

Michelle Laverick

Michelle Laverick.jpg

Barry Coombs

Screen Shot 2014-04-28 at 09.41.39.png

Video Content [TBA]

Introduction: Understand Your Users

Version: Horizon View 5.1

We could write a whole book regarding designing your VDI solution, what we intend to achieve with this chapter is to give you enough knowledge to ensure you are asking the right questions, investigating the right areas and understanding the different elements that need to be considered when not only designing but planning your VDI solution. Why VDI design and not VMware View Design? What we are going to discuss in this chapter are concepts that are applicable to most VDI and server side computing solutions on the market today. We will cover the intricacies of the various different components in each of the relevant chapters in this book.

This is something that can very often be overlooked, if you design a VDI solution without fully understanding or consulting your users you will be very lucky if the final solution meets the requirements of the users and more importantly the business. VDI design is very different to that of Server Virtualisation, we are directly affecting the way users work and whilst many IT administrators may believe they understand the way users work within their business they usually don't have the complete picture.

We would recommend the very first step in a VDI design is an information collection exercise, there are a number of ways we can do this but what is most important is that we can answers questions like:

• What applications do different users use? • What hours do users work? • What specification PC's do the users currently have? • How are their PC's performing?

Once we have gathered this kind of information it will help us not only design a better solution but build the right solution for the business. We don't believe that VDI is yet at the stage of server virtualisation where every workload can be virtualised and we need to identify those users now, not after we have tried to force-feed them a virtual desktop.

We believe that collecting this kind of information using tools by companies such a LiquidWare Labs, Lakeside Software and Centrix Software will be a huge asset. We are able to monitor the users workstations and collect the statistics that will not only help us size our solution but understand how the users are using their desktops. But the most important point is talking to the users and understanding in real terms how they use their desktops. We have found that by finding "Champions" in different areas of the business to help you not only understand how the users use their desktops but also to help with testing your solution you will get a lot higher success rate when rolling our your finalised solutions.

Next Generation Desktop

There is a very basic concept that a lot of vendors are currently describing as "The Next Generation Desktop", with the next generation desktop we are aiming to unlock the three key areas of the desktop from each other in the same way that we have unlocked workloads (Virtual Machines) from physical hardware with server virtualisation.

Screen Shot 2014-04-25 at 16.17.23.png

By unlocking the persona, application and OS you are separating the need for a user to take ownership of a particular desktop or a physical machine, this results in flexibility for not only the users but for the desktop administrator. This will also help to significantly reduce complexity and possibly cost of your chosen VDI solution. We will start by looking at what each of these elements are and how and why we look to unlock each of these elements from each other.


The persona is everything that makes the user's desktop theirs, we are talking about their documents, settings, customizations. The persona is often the part of the desktop that causes the most grief, when a users physical desktops dies the largest pain will be in the fact that documents have been lost, that weren't saved to a network drive. Also that their customizations have been lost meaning a period of reconfiguration will need to take place by the users before they are able to continue with their work on a new machine.

In our view the persona is one of the most important aspects of a successful VDI project and the one that often gets overlooked the most. With a VDI solution as often as possible we will look to configure the users with non-persistent desktops, these are desktops that can be allocated to anyone. If the users persona is tied to one particular virtual desktop it will mean that we need to manage and maintain that one desktop just for them. By separating the persona from the virtual desktop it means that any users should be able to be assigned to a floating desktop and continue where they left off with no interruption. There are a large number of ways how we can achieve this, many that are available to use with no additional cost.

The first we would like to talk about is roaming profiles, we are sure you are all familiar with roaming profiles, understand why we have tried to use them in the past and found the pain they can cause, the concept of the roaming desktop is exactly what we are trying to achieve with Persona Virtualisation. Now whilst roaming desktops would help us achieve the required effect, we don't believe this would be a wise move, the main concern with the roaming desktop is the fact that when a user logs in the contents of the roaming profile will be copied to the desktop, this can lead to long log in times and in a VDI scenario a huge increase in the IO required to deliver the desktops.

What does work well in a VDI scenario is a redirected profile solution, there are a number of ways we can achieve this from Windows Group Policy to VMware's inbuilt profile redirection technology that has been introduced in View 5 to more advanced solutions such as RES Technologies vWorkspace or AppSense Environment Manager. What is important is to understand the end users needs, try the technologies and evaluate what is best for your business.

The advantages of a third party product such as RES vWorkspace are that we can add another element to the persona and this is location and device awareness. Think about an educational environment and ensuring when students log into a desktop in the science classroom, they need to have access to the science applications and the local printer, technologies allow us to take the persona this stage further.


After the persona for the user the applications are probably the most important area of the desktop for the users. If we had a business where everyone uses the same application this would probably be a very easy area of our VDI solution. In the real world applications are often the causes of many headaches, different departments will use different applications, different people within each department will have special use cases to use different applications, and maybe we need multiple versions of the same application for different people across the business. With a traditional method of installing the applications within the desktops this would be a nightmare to manage in a VDI environment, we would most probably nearly end up with a dedicated desktop for each user. Also keeping those applications up to date can been a challenge. This is where application virtualisation steps up to the mark, with application virtualisation we are able to run applications from a single executable in their own bubble, meaning we can stream the applications to the users that require them, allowing for fewer pools to be created but still insuring each users is able to have the application required to do their role. As we are talking about View 5 in this book we will assume you will be using VMware ThinApp to virtualise your applications, although there are a number of solutions on the market such as Microsoft's App-V that we could use to achieve application virtualisation. By packaging your applications in such a way it opens the door to a wealth of technologies for application distribution whether you have virtualised desktops or not, VMware are leveraging ThinApp technology in a number of ways one example of this is by creating an Enterprise App Store with VMware Horizon, we have more information regarding this in the final chapter.


The final piece of the puzzle is the OS (often referred to as the desktop but realistically the desktop is made up of all 3 of these elements) arguably the most unimportant element to the end user, as long as they are using an OS that is familiar to them and they can find the applications and their documents most users will be happy. By separating the applications and the persona from the OS it means that we are able to manage the OS as a separate entity, this allows us a huge amount of flexibility when it comes to updating and locking down the desktop. Of course this is where VMware View will step up to allow us to virtualise the OS (desktop). Also now as our application and persona are separated we can deliver a number of the VDI benefits to the users that may not be able to use a virtualised desktop because of their workload or maybe because you are going to do a staged rollout.

Designing your solution

Now that we understand our users and understand the layers of separation we are trying to achieve we can start designing our solution. We will firstly use our data collection to understand what the performance requirements for the various elements inside our solution.


We are going to start with disk - as this is an area that we have found to be one of the biggest causes for failure in VDI solutions. When each users has their own physical desktop, they each have their own spinning disk, these disks will usually be your standard 7.2k SATA disk and for this fact people often overlook the need for disk performance when it comes to the VDI solution. In real terms each one of these disks is conservatively capable of somewhere in the region of 70 IOPS. If we start to do some basic math we can see how to deliver the same IOPS in a VDI environment we are talking about a sizable solution.

100 users x 70 IOPS = 7000 IOPS

Now realistically our users won't be using their disks to full capacity the majority of the time with the main exception being during boot and logon. Two of the biggest enemies of our VDI solution are boot and logon storms. When the desktops are booting and when users are logging into the desktops the hard disks get the hardest hit. There are some easy ways we can help overcome this by redirecting profiles as we have previously mentioned and also be ensuring the virtual desktops are booted out of hours.

Despite this we still need to take the IOPS requirement seriously and size our SAN accordingly. VMware have published a number of papers on this subject and the rough figures they gives us for IOPS per user are between 5 IOPS per user for a basic task work and 15 IOPS for a knowledge worker, these figures will also vary based upon the operating system as XP generally uses less IOPS than Vista or Windows 7. We have found these figures to be slightly on the low side in some of our previous design scenarios.

Our recommendation would be to use the information gathered in your data collection stage to ensure that you understand the IOPS information for your users, do understand that we are going to try and reduce the IOPS per user by completing a couple of steps and use a proof on concept to help you understand what your actual requirements are.

Most SAN vendors have hybrid arrays on the market at the moment that will boost spinning disks with SSD's meaning you don't have to buy a large amount of spindles to meet the IO requirement when you only need a relatively small amount of data. You may also want to consider using local disks in the ESXi Hosts instead of a SAN for your VDI deployment, of course if you decide to do this there are a number of considerations over and above ensuring you have enough spindles or SSDs to meet your bandwidth requirements, you may also need to over allocate each of the pools to ensure there are always desktops available if you have a host down scenario, by using a SAN for your desktops you can utilise VMware HA which wont be available with a localised storage scenario.

Also introduced in 5.1 in the content based read cache that allows the most commonly read blocks to be cached in the memory of the ESXi hosts. A large amount of the IO in a VDI environment will be writes but the read cache may help you lower the overall requirement on the SAN. We would suggest you test the effect of the content based read cache during a proof of concept to gain a full understanding of how it would benefit your environment.

Another important factor to consider is the amount of space that will be required to store the desktops, this will be differ greatly based upon your decision to use VMware View Composer to create linked clones which will reduce storage space or not. Over and above the size of the desktops itself you need to also ensure you have think about the following

Virtual Machine Swap Files By default these will be equal to the size of the memory allocated to your VMs

Disposable Disk Size

It is recommended that you create a disposable disk if you are using View Composer to limit the growth of the linked clones between refresh operations.

Persistent Disks

If you are using persistent disks for any of your users for part of your design you will need to ensure you have taken into consideration the size of these disks.

Template Size Often overlooked is the size of the actual templates that you will be using to roll out your desktops or master images from

Thin Apps Storage space required storing not only your completed Thin Apps but also your project files

Persona Storage location for the users Persona’s whether you are using the inbuilt persona management or a third party solution.


Considering the number of processors needed in our VDI solution is one area where a little bit of previous knowledge will help you immensely, you will get a feel for how many virtual CPU's you can virtualise compared to the amount of physical cores in your server. VMware's current guideline is that you should be able to achieve somewhere in the region of 8-10 virtual CPU's to every physical CPU in a VDI environment. We would advise taking this figure with a pinch of salt, your level of oversubscription of vCPU's on physical cores will depend on a number of factors, we would recommend again using the information gathered in the data collection stage to understand, how many cores the users currently have in their desktops and how they are utilising these cores. What OS you are going to be running on your virtual desktops can also affect this quite a lot, if you are going to be running Windows 7 you may be more likely to need 2 vCPU's per desktop for more users than you would if you were running Windows XP if you take VMware’s sizing guidelines into consideration. Also when designing the amount of CPU's and Core's that are required for a VDI environment keep in mind that we are normally still looking to run HA to protect our desktops so we will still want to use the N+1 or N+2 methodology when sizing our environment - keep in mind that we are also limited to 8 physical hosts per cluster with View Composer and Linked Mode.

The easiest way to understand how far we are going to be able to push vCPU over provisioning is by examining the performance graphs in vCenter during a proof of concept. The most important figure to keep an eye on is CPU ready, this is the time a vCPU is waiting to be able processes it's data on a physical core. Keep in mind that you have users physically interacting with the desktops on a VDI solution so you would want to keep this figure slightly lower than you may expect on a server virtualisation solution, we have found that with a VDI solution we aim to keep the CPU Ready below 5% to ensure there are no user experience issues where as with a virtualised server you may allow this figure to be higher. The true figure that will be acceptable in your environment will only be found when you complete adequate testing during a proof of concept stage.


We have found that memory is one of the easiest to calculate in a VDI solution, the primary reasons for this is that we don't usually over commit memory in a VDI solution, the primary reason for this is that the last thing we would want to happen in a VDI solution is memory swapping to disk, this would have huge knock on effects for the users. As such we have found that by ensuring there is enough memory in the physical hosts to cope with the required number of desktops, the overhead to run these desktops and your N+1 or N+2 for HA has been the best bet.

We also need to consider that as standard with no memory reservation there will be a swap file created that is the same size as the memory in the virtual machines. Now as we aren't looking to over commit memory we could consider setting a memory reservation per VM of 100% of the memory allocated or a more affordable option maybe to redirect the swap files to some local disks in the hosts.

External Connectivity, QoS and Bandwidth

The area of bandwidth and connectivity is often overlooked particularly if the VDI implementation is undertaken without the assistance of a networking team or someone that is knowledgeable regarding networking, often if a proof of concept is successful it will proceed to a full blown role out without further thought to how the increased user count may be effected by the available bandwidth. VMware have given some bandwidth sizing guidelines in the VMware View Architecture Planning Guide these are as shown below.

For these examples we are assuming you are using PCoIP as your display protocol, with the enhancements to PCoIP in View 5 and up to a 75% reduction in bandwidth, PCoIP has become the de facto standard when using View. Bandwidth Requirements for Various Types of Users

When determining minimum bandwidth requirements for PCoIP, plan with the following estimates

50 to 100Kbps average bandwidth for an optimized office productivity desktop: typical office applications with no video, no 3D graphics, with Windows desktop settings optimized and VMware View optimized.

400 to 600Kbps average bandwidth for virtual desktops utilizing multiple monitors, 3D, Aero, and Office 2010.

500Kbps to 1Mbps minimum peak bandwidth to provide headroom for bursts of display changes. In general, size your network using the average bandwidth, but consider peak bandwidth to accommodate bursts of imaging traffic associated with large screen changes.

2Mbps per simultaneous user running 480p video, depending upon the configured frame rate limit and the video type

Possibly the best way to size your bandwidth requirements would be monitoring and documenting bandwidth usage during a proof of concept. With the introduction of vSphere 5 there are a lot more metrics available to third party manufacturers to help with monitoring the PCoIP protocol, both Liquidware Labs and Xangati have solutions that may help you do this as well as any standard monitoring tools you may be using. Whilst completing a proof of concept it is also important to note that PCoIP can be further optimised to help you get most out of your available connectivity.

After calculating your required bandwidth you will need to decide how you are going let users connect from the external world, VMware ships the View Security Server with View 5 that allows you to broker your PCoIP connections through the secure PCoIP gateway in your DMZ, but if you want to make use of existing solutions such as VPN devices it is important to remember that PCoIP is a UDP protocol and if your VPN device is TCP based and will wrap the PCoIP protocol inside a TCP packet it will have a severe effect on the performance of the PCoIP protocol, you must ensure that your VPN device supports both TCP and UDP. Another element for consideration is no part of VMware View contains a load balancing solution, this means when you start to scale the solution you will need to load balance the connection between multiple View Connection Servers with a third party device. We have included a dedicated chapter covering load balancing with VMware View.

Finally we want to talk about Quality of Service (QoS) and the PCoIP protocol, as we have already mentioned the PCoIP protocol uses UDP packets to transmit its data, PCoIP uses UDP like many other real time applications, such as VoIP and Video Conferencing. By the nature of UDP it is send and forgot, there is no error checking to ensure the packet gets there and retransmits if it doesn’t. As the data we are dealing with is live data, having a packet retransmitted until it finally gets there is of little use. As such like VoIP and Video Conferencing it is a wise choice to ensure you configure QoS for the PCoIP protocol, the downside is if you don’t a large number of networking devices will put the UDP packets at the bottom of queue, this could cause issues for user connectivity particularly between branch office and head office. Similarly there are a number of L2 and L3 features that can adversely effect the PCoIP protocol, these include but are not limited to buffering and tail drop, buffering will mean that the packets get stored and forwarded from the router to help alleviate dropped packets when the bandwidth is fully utilised, but of course with a real-time use case such as VDI this is of no use at all, with tail drop packets will get dropped until congestion is alleviated, in favour of using these congestion techniques you should investigate the usage of Weighted Random Early Detection that will use advanced congestion avoidance algorithms to help avoid congestion.

This is only a taster for some of the elements you need to consider when it comes to networking and you VDI environment, we could probably write a whole book discussing and explaining how to configure your networking for optimal use with a VDI environment, for more information and further consideration please ensure you read the VMware View PCoIP Network Optimization Guide that will give you a full run down on best practice.

Desktop Image

There are a number of elements to consider when designing the desktop images, you will base a lot of these decisions on your data collection and your users needs, such as how many vCPU's, what OS etc. But there are a number of things we can consider and steps we can take to ensure we can get the most out of our solution.

A lot of the time the introduction of VDI solution can be seen as a good opportunity to lock down the user's desktops more than has ever been done before. We can see why this maybe considered at this time but we would ask for you to think of it in this way, when you introduce your new VDI platform to the users you are likely to be alienating them from it straight away not because the introduction of the VDI solution but because the new restrictions that have been placed upon them. We would advice taking a staged approach so the users can get used to the VDI solution and then introduce the new lock downs over time so the new VDI solution doesn't seem to be the cause of these new restrictions. The final aspect to consider is the optimization of the image, there are a number of elements inside the Windows operating system that will never be used by your users and may cause increase in performance and size of your desktop images. There are numerous white papers around about how to optimise your desktop images such as the VMware View Windows 7 Optimisation Guide so we are not going to go into great detail around the how to optimise your desktop, but ensure you also consider what you are removing when optimising your desktop for the same reasons as above. We have seen some great results from using the free Quest vWorkspace Optimizer on our desktop images prior to deploying them using any VDI solution.

Desktop Pools

Often desktop pools will be based around business units of roles with a company, consider when you are creating these pools the requirements of the users. How many people are going to be using these pools and if you are creating a pool for a smaller number of people could they share a pool with another group of users. By reducing the number of pools inside your environment you are making the administration a lot simpler and potentially saving money from not just an operational expenditure point of view but from a capital expenditure point of view with a reduction on disk space required.

Client Devices

Obviously an important decision when rolling out a VDI solution is the client devices as at the end of the day this will be the first element a user will notice. We aren’t going to dig too deeply into this section as we cover thin clients and repurposing PC’s in a later chapter, but it is important to ensure you are considering the end users needs and use cases when choosing your client devices. There are many different client devices available for connection to VMware View and it is likely that you will end up with a mix of devices, certainly with the continued consumerisation of IT, it is likely that at least some of your users may wish to connect to their desktops externally if not internally as well from an iPad or similar tablet device. There also isn’t a one size fits all solution when it comes to thin clients with certain clients being more suitable for multimedia work, others offering greater ease of management etc, please turn to the thin client chapter for a greater insight into your choices in this area.

Proof of Concept

As we have mentioned several times the proof of concept stage is highly important with any VDI deployment, whilst server virtualisation can sometimes be deployed as an out of the box solution, VDI is very specific to a business and how they work. The proof of concept allows us to see how our solution is going to work, get the departmental champions involved to test how it is going to work for them and help you tweak the design to meet the businesses needs, finally understand the consolidation levels you will get from a final design and ensure you can deliver the solution inside your budgets. Whilst your proof of concept may go well it is important to ensure scalability is addressed at this stage, by failing to design a solution that is going to scale correctly you will be sure to fail as more users are added.


This has been a very brief chapter regarding what is one of the most important aspects of your virtual desktop infrastructure. We hope it has had enough content to be thought provoking so you are able to go away and research each area to ensure you have a good foundation to your desktop virtualisation project. There are a number of key elements that must be considered but beyond the hardware requirements understanding your users and your business will help you enormously when it comes to implementing your virtual desktop solution. In our next chapter we will be getting our hands dirty by installing the core components of VMware View 5.