Category Archives: VDI

[VMware] VDI Requirement Gathering

Oh! it is been a month i haven’t written a single post. Ah! Blogging is my favorite activity. I love sharing my experience and learning. This the single most platform I can express my thoughts on technical front. I don’t know how many of you like  but I don’t see that as motivation factor. In all cases I would love to hear back from you. Recently I did a VDI requirement gathering workshop with a customer. Based on various design meeting I have come across questionnaire. I would like to share with you. You will need to basic understanding VDI especially technology you are supporting. First and foremost and most important why are you looking towards VDI. Don’t start with Why question. Rather I suggest you put across a question in way a your customer understands. It is worth noting first meeting will be with IT manager, CXO. They would understand if you ask them what is the primary objective in exploring VDI options.

What is the business goals/Drivers for VDI?

Security, Cost saving, desktop refresh. These are few of the options which can help you to drive the discussion. Without understanding each of the Business drivers your conversation will be more like Q&A. It should be discussion. If desktop refresh is one of the drivers, then immediate question would be to understand if existing desktops can be reused. Are the existing desktop end of life.  Since existing desktop will be used, it is very likely user might use both the desktop. It is opportunity to ask where users will be saving their data. It would also give you insight that you need some profile migration tool in place. Since we are here, whether users are using PST and if they are storing in some central location. Here is reference on this topic. This post also provide you likely solutions

What applications will be used via VDI Desktops and What is the nature of this application?

This is most important thing I learnt from Brian Suhr book. VDI is all about apps and not about desktops alone. How you present Applications (apps) to the end user. iPad, Tablets,Phone and Cars is of utmost important. Entire focus of your discussion should around these applications. Who is using these application and what they are doing with these applications. Are there is common set of applications used across your organization? Are there heavy graphics, High I/O (Autocad, Visual Studio), Memory Intensive CPU intensive (Graphics), Recording Audio application in used. Are these application business specific, can these application be down? This discussion will help you decide 1.) if you need a multiple desktop pools 2) Do you need any application virtualization feature. This could be easily guessed, more variation in applications portfolio, more will be inclination to separating application from desktop pool . Most frequently used application can be part of standard image or can be thin app’ed. This is very well explained in Brian’s book. In each case you need to the count of users who are using this application. e.g. If photoshop users are only 5 and they just use it for light graphics you probably don’t need grid cards. If these are heavy graphic users along with considerations of Grid cards, you are very likely to consider to Monitor size and resolution. You could see how one question leads to answer to another. Now that you understand the nature of application, most critical part is how license works. e.g. Office licenses need validation and it need license management server (KMS).

Are there any users who need to install applications on local desktops other than desktop admins?

Now this is one of the use case for persistent desktops. If there are developers in your organization who need pool of applications, they obviously need administrator access and much more. As could be easily guess, you must know how many developers/users with this requirement are needed. This will drive the DR strategy for persistent desktops. Along with, you need to know how critical is their nature of work. Here you can pause and ask how frequently application refresh occurs and how applications are refreshed. This is critical piece of information as these will impact application virtualization and it’s efforts need to update. e.g. If application-A is refreshed every month (yes there are applications which are refreshed every month), and if you are proposing application virtualization for these set of application, you need to consider how are you going to ensure these updates are integrated. This is on-going cost and may vary based on complexity of application. yes I’m reading your mind “App Volumes”. Yeah!, do you need to be architect to say/propose it. Think again!!!

Are users working in shift?

If yes, what is anticipated concurrent users. This will help you decide licenses for VDI and CALs. This will also help you decide % of users who need floating desktops. e.g. if there are 300 users working in a 3 shifts, i.e. 100 users per shift. You just need 100 Concurrent user licenses, you can provide 5% allowances and procure licenses. Floating desktops is must here. CALS refer to end user CALS for desktops or RDSH if you are offering RDSH based desktops. This could be also appropriate place to understand if Terminal services licenses are there with customer

What is anticipated total users (if they are not shift users)?

This will help you identify license requirement for AV, Software licenses for Office, Desktops and other product which do not based their licensing concurrent users. You could relate difference between 300 licenses or 100 AntiVirus license.

From where end users are going to access desktops/applications?

This help you understanding how access has to be granted to the end users e.g. WAN/LAN/Internet. If there are Multiple sites, what is the required bandwidth between these sites. How users are going to access from the remote site. (thin client/Desktop/Laptop). Internet: They could be mobile users, working from home or working from office. Number of users, number of applications they need to access will have direct impact on bandwidth and latency required

Do you need access to desktop from home?

Yes it is not application access but desktop access. If yes, there is whole lot of security considerations. You need view security server or identity access appliance. Identity access appliance would be suitable if there is sufficient VMware Infrastructure in DMZ. All users would need access from Home? Do users needs two factor authentication? if Yes, RSA token is license per user. Is access from Home critical? or it is access on best effort basis. It will drive your high availability design. Again you will need restrict VDI Desktops to specific VLAN

Is user using Lync/Audio/Video user ?

Lync will have direct impact on selection of thin client. It must support Lync plug-in. Zero client definitely do not support it. Factors like features, cost, Design and performance.

Do you need USB devices/Scanner/SmartCard Readers redirection?

This is often forgotten. User need USB devices for various reason. It must be able to accommodate this requirement. In hospitality industry things become more critical when they need to move between room attending patients. This requirement will have indirect impact on your selection of endpoint device.

List down the agent installed on the desktop

  • AV Agent
  • Backup Agent
  • SCCM/LANDesk Agent3

Do you still needs these agents in VDI Desktops? Backup Agent? definitely not. You no longer would be taking desktop backups. would you?

Following questions will help you build supporting infrastructure

  1. Do you have Certificate Authority? If no, you either have to recommend one to be prerequisite(read this post from Harsha) or assist them in building one
  2. Do you have Load balancer in your existing solution? If no, you can either procure on behalf of them or ask them to in pre-requisite list? If they need active active VDI solution, then Load balancer should be intelligent to divert traffic based on source IP
  3. Do you have SRM? If DR strategy is Active-Passive, then SRM will assist in DR failover to VDI components. Refer this white paper for further details
  4. Do you have terminal server licenses? If yes, you can explore the possibility of providing RDSH to the customer for select applications
  5. Where users are storing data? local desktop/laptop? then you must considered file server in your design for user data and probably for PST as well.
  6. Do you have DHCP server at  site? Is it redundant?
  7. Are there any non-corporate users accessing desktops? e.g. Vendor, contractors? How these users prohibited from accessing corp data?
  8. How are using connecting to the network? These will have direct impact on users endpoint.

This is just the tip of iceberg. If you follow this questionnaire, I’m sure you can built your own based on your experiences. Biggest advantages of this questionnaire is, it allows you to build requirement gathering document without much effort.


Availability & Recoverability Matrix of View Components

While working for one of the View Design Project, I have to do lots of reading to ensure Horizon view components are highly available. Eventually I felt it would be excellent idea to  create below matrix to find Single Point Of Failure (SPOF), and how to address the SPOF at each layer (Service, OS, Hypervisor, Storage). Below I have listed main components in View, what are potential failure points and ways they can be addressed.

So, We made a Design decision to protect Horizon View solution  using Windows Server Failover Cluster (WSFC)

In most of use cases, vSphere HA is sufficient to meet the availability of solution. With vSphere HA, If esxi Host reboots  Guest OS and its application is back in operation in less than 15 minutes. Please note standard is less than 5 min but remember application also need some time to start. I’m referring to generic application not an application which has multi-dependency. e.g. vCenter has down stream dependency on Database, DNS

Let’s first find out  what are all scenarios vCenter can fail. vCenter as VM can fail if ESXi fails, vCenter as Guest OS can fail, if OS gets corrupt/Virus attack, vCenter as service can fail, may be because database is unavailable and for other reasons cause could be many.

What are various protection mechanism for each type of failure?

  1. vCenter as VM & OS will be protected using vSphere HA, it will restart but then there is 10-15 mins delay before vCenter is back in operation.
  2. vCenter services can be protected using in-built watchdog and by protecting vCenter services using Microsoft failover cluster. In this case vCenter can return to operations in less than a min. But heart of vCenter i.e. it’s database still remain SPOF.

Accordingly each component is tabulated below


ESXi Failure

OS Failure

Application Failure

Impact on Availability

Special Configuration


Reboots vCenter Node

VM monitoring with VMware HA will attempt to restart OS. 

vCenter services are seamlessly failed over to second node.

near zero downtime

Minimal impact as services are offered by second node

2 node MS Failover cluster must be configured & Need to configure Anti-affinity rule

MS SQL Database

Reboots SQL Server Node

VM monitoring with VMware HA will attempt to restart OS

MS SQL services are seamlessly failed over to second node. Near Zero downtime

Minimal impact as services are offered by second node in MS Failover cluster

2 node MS Failover cluster must be configured

& Need to enable Anti-affinity rule

View Connection Server

Reboots View Connection Server

VM monitoring with VMware HA will attempt to restart OS

Load Balancer removes this node from membership so that traffic Re-directed to other nodes.Zero downtime

Zero impact as services are offered using other nodes in Load Balancer

Need to enable Anti-affinity rule

View Composer

Reboots View composer Server

VM monitoring with VMware HA will attempt to restart OS

No in-built protection. 5-10 minutes downtime.

VM is rebooted, Impact provisioning, Recompose operation during the outage window


Reboots File Server Node

VM monitoring with VMware HA will attempt to restart OS

File services are seamlessly failed over to second node.Near Zero downtime

Minimal impact as services are offered by second node in WSFC cluster

2 node MS Failover cluster must be configured & Need to enable Anti-affinity rule.

Design Justification

  1. Number of components (as per downstream figure below), are dependent on Database (MS SQL in our case), unavailability of database can potentially bring entire solution down
  2. Even if database can protected using vSphere HA,  database might take 15 minutes to be back in operational. Post that vCenter database might take another 15 minutes to come up, as vCenter service is dependent on vCenter database. Similarly view composer service will need 15 minutes to be back in operational. But vCenter and view composer service can come on line together if they are co-located on same server.
  3. Post that View connection server will be able to send commands to vCenter and view composer.
  4. Below explains the delay from the point database server rebooted till view connection server is ready to send any operation command to vCenter/View composer. If WSFC is not used, view solution might not be available for minimum 30 minutes

    Horizon View Availability Impact with no WSFC
    Horizon View Availability Impact with no WSFC
  5. With WFSC cluster if database server fails, in less than 5 min database failover happens, vCenter / View composer service are not impacted and therefore no impact on view connection server.
  6. vCenter database is heart of vCenter. vCenter database must be highly available.Since view connection server has dependency on vCenter for various operation, unavailability of vCenter will impact vCenter, view composer, view connection server.
  7. WSFC will protect  vCenter services against OS failure, ESXi failure and Service failure.
  8. View composer database will be protected by WSFC. View composer service will not be protected using WSFC. vSphere HA for applications will protect against OS and Service failure. There is potential downtime of 5-10 minutes

    WSFC is complex to configure and manage. Considering the impact it can have on over all availability of solution, efforts in installing, configuring and managing WSFC are worth the efforts. With WSFC, maintenance of all components can be done without having any significant downtime all components are redundant.

    Downstream Dependency Map


    As technical architect we can easily conclude, not having WSFC can bring the entire solution down. If it was just vCenter it wouldn’t need to have WSFC but as dependency on vCenter services increases, your architecture must balance complexity with availability.

Power Policies for Desktop Pools

I recently finished reading VCDX Boot Camp: Preparing for the VCDX Panel Defense. This is second time I’m reading the book. It is great refresher and as Technical Architect (which is my current role) aids me a lot in gathering requirements and how to validate the requirements of clients by focusing discussion around it. It has helped me rewiring brain. Made me think in terms on AMPRS*. Good Read (5 stars). Angelo Luciani wrote a very blog on chrome extension. I came across Instapaper chrome extension and started using it. Very helpful. As result i bookmarked some great post. During week reading, I read a very good blog post on Risk Management. Please read it, if you are aspiring to be Architect. Risk management is so crucial in decision making and how frequently we miss it. Weekend reading, i came another interesting post on Assumption by Simon Long. I was surprised on what we do not Assumption in our design documents. I have seen it in every decision document. Assumption must be either validated or posted as a Risk if it cannot be validated.

Point is my blog would probably never post on “How to” anymore. It will be always “Why”. Question “Why” is important question to ask yourself and client. Hope I haven’t bored you with it. Lets talk about subject of this post.

I was looking at Power policies we configure while creating Desktop pool. I felt it is most ignored/not so discussed settings. When I went through, I felt it needs to be visited. Hope the post allows you make decision on why to select particular power policies. There are four policies from which you can choose from. These  policies controls what happens to the desktop when user logs off from the desktop


Following are the 4 policies you can choose from

  1. Take No Power Action
  2. Ensure Virtual Machines are always Powered On
  3. Suspend
  4. Power of

Below I have tabulated all four settings in details with description, behavior of policy and its impact


Power Policy

1.    Take No Power Action

Behavior of Policy

As policy aptly named “Take No Power Action”, View connection server (VCS) do not control the state of VM. When End user change the power state of VM, state remains unchanged with small exception. Exception is when user logs off from VM, VM state remains powered on. However when View administrator initiates recompose operation, VM will be powered off. So power state is changed. VM remains powered off even after recompose operation is completed. 

Case 01: If user is assigned a dedicated desktop. User logs off end of his day as he is going on vacation. Recompose operation occurs while he is on vacation, as result VM is powered off. Till he returns, VM remains powered off. He has to log a call to helpdesk to see why his VM is not reachable. Log in time + Application launch time (e.g. AV if it is agent based) is increased. Uptime is low and user experience is negatively impacted.

Case 02: If user shuts down his VM end of this day. VM is powered off. Next day he logs in, VM is powered on. Again Log in time + Application launch time (e.g. AV if it is agent based) is increased.

Use Cases:

  •         Those users who need shutdown privileges. (Shutdown privilege is never given to end user without good justification)
  •         Dedicated desktop users might need shutdown privileges.
  •         Where desktops uptime is little concern


·         If there are any agents which are pulling data from desktop e.g. system management will be impacted.

·         Administrator overhead and IT helpdesk might be overloaded with tickets post recompose operations to power on VMs

·         Impact can be reduced by keeping minimum of VMs powered on to half the size of pool

·         Suitable for dedicated desktop when the % of VM is less e.g. 10% of overall population. Out of 100, if 10 VMs need to powered on, it is a little operation effort. If count goes beyond 50, effort needs to be estimated.


2.    Ensure machines are always powered on

Behavior of Policy

VM always remains power on irrespective of user action. Post recompose operation, VMs are automatically powered on. E.g. If user shuts down the VM, VM is automatically restarted by vCenter. And during recompose operation, VM is automatically powered off and post recompose operation VM is automatically powered ON

Use case:

·         Highly effective for shift workers. In shifts, 24 x 7 desktops will be consumed.

·         If dedicated desktop count is high e.g. above 50 desktops


·         VM always remains powered on, there is no boot storm. Therefore reduced log in time as VM is always powered on.

·         For dedicated desktop pool Administrative effort is reduced. Administrator might spend time to identify and power on VMs

·         Shutdown privilege is ineffective. Shutdown privilege must not be given.

·         For linked clone pool, there is little need to keep spare VM powered on as VMs are always available

·         Potential Resource wastage if all VMs are powered on without being used.



3.    Suspend

Behavior of Policy

VM is suspended when user logs off

Use Cases:

·         Compute resource needs to saved i.e. power needs to be optimally utilize but login time must not be increased


·         IOPS needed to suspend and resume VM will be high. Additional IOPS requirements needs to be consider

·         Once suspend, file is created it remains in VM parent directly till VM is powered off. Extra storage needs to be calculated.


4.    Power off

Behavior of Policy

VM is powered off, when user logs off

Use Case:

·         Disk space is constrained. During power off operation, independent disk will return to pristine state.

·         Desktops are consumed only during 9-6 operations

·         Power must be optimally used


·         Boot storm + login storm every morning. Impact is directly proportional to number of concurrent desktops logins. Can be mitigate if user login time is staggered.

·         Post recompose operation, Administrator have to manually power on all VMs. Can be mitigate using powercli script. Efforts and skills would be needed to develop script

*AMPRS :- Availability, Manageability, Performance, Recoverability and Security

View Connection Server Tags

When I read it first, I thought I got it but when I attended question around it I failed. Glad that I failed, at least I learnt it thoroughly now. By default all desktop pool are available from all connection servers. e.g. User can access desktop as long as he is entitled to at least one desktop pool and connected any connection server. View connection server tags is the way to restrict a desktop pool to particular view connection servers. As part of security requirement you can restrict view connection server for particular set of desktop pools.

In figure below end user-A is entitled to Desktop pool 01. Connection server 01 is configured with connection tag as Gold. While creating desktop pool we associate connection server 01’s Gold tag with it. When end user selects connection server 01, he is able to go to desktop pool 01 as Gold Tag of connection server matches with Gold tag on desktop pool. But when he select connection server 02/03 he is not able to connect to desktop pool as connection server do not have tag associated with it. Connection server denies the access


Case 02 : User-C is entitled to Desktop Pool 02, user selects connection server 01 but he is denied access as Connection Server 01 only grants access to desktop Pool 01. So User C selects connection server 02/03, since no tag is defined on connection server 02/03 user-C is authenticated and presented Desktop Pool 02.

Simple Tip: Think connection server as Ticket collector who helps/advice you in finding seat (desktop). He will see the ticket (tag) and try to allocate the seat (desktop pool). If ticket (tag) is matching seated is granted. If ticket(tag) is not matching, you are not allowed in i.e. access is denied. Similarly when User-A tries to use Connection Server 02/03 there is no tag created on connection server i.e. there is not ticket collector, therefore there is no one to guide you to Desktop Pool 01. But when User-C logs into connection 02/03 he directly given desktop in desktop pool 02 as there is not tag which needs to be validated by ticket collector (Connection Server Tag)

Connection Tag Internet Facing users

View Security servers must be paired with connection servers. If view security servers are behind load balancer, you must ensure security server is paired with connection server where the tag is defined. In below example I have created tag on connection server 01 and connection server 03. In case either of security server01 or 02 fails, user which are entitled to desktop pool 01 are able to login. It makes Fully redundant solution. tag01_SecurityServer

Hope you find this useful. I can’t believe as started drafting this post I learnt lot many other things around connection servers and tag. Keep writing & posting. Happy Monday

Mindmap for selecting between Persistent or Non-Persistent Desktop and Endpoint selection

I’m feeling quite great for two reasons 1) I have finally learnt how to use mind mapping 2) I’ve have rewired my brain to think of dependencies and impacts. Below is the mind map which will aid in selecting persistent or non-persistent desktops. Idea is provide dependencies, pre-requisites and use cases. In previous post, I had similar intentions and I will continue the theme till I feel comfortable about it. In below figure, three important inputs you would need

  1. User profiles (Task worker, shift worker, Heavy user)
  2. How many desktops you are planning and how are these desktop maps to the user profiles e.g. how many of them will be used by task worker ?
  3. Endpoints used (will you use existing desktops?)

In order to make decision between persistent or non-persistent desktop pools, you may start reviewing use cases first. However I’m starting from top i.e Potential Implications (Road Blocks in using non-persistent desktops)


1. There is requirement to retain temp files, user activity logs , there is requirement for forensic or compliance on data retention especially of user activity. This is first solid requirement which discourages for use of non-persistent desktops

2 Floating pool is allocated on first come first bases. So, if there is failure of desktops, user just login back using view client and he gets the desktop in less than a minute

3. Recoverability as long as there are additional desktops in pool, Desktop is immediately available for use e.g. 300 desktops are provisioned and only 275 desktops are in use, 25 will be available for use in case desktop fails. However if ESXi fails there is chance that user have to till VMs get rebooted on other unless VMs are to catered towards N+1 failure even at VM level

3. Application licenses are to be procured for total number of desktops e.g. AV (Unlike concurrent users license e.g. VDI Desktop license and or RDS CALs)

4. In order to achieve unique desktop experience for each user, persona management is must.

5. Use cases: This is the crux. e.g. Most of the users will be roaming and will be using different desktops/endpoint everyday or users will be shift workers or solution must support DR or application is virtualized using App-v/ThinApp. All these use cases will drive your decision towards non-persistent desktops. Similarly discussion can be done on left hand side (Shown below) for persistent desktop.


To keep things simple I have not shown the entire mind map. I hope this will help you in driving conversation in right direction and making right choice for the customer. I’m fairly new to VDI therefore I might miss few important design factors. I’m always happy to hear it and learn from it.

Let’s look at VDI end point selection mind map. I suggest you start from the tail here i.e. are you going to do a greenfield and if yes, how many of VDI desktops will be audio/video


Are you going to repurpose desktop? Then how about OS licenses? Is security a primary criteria?

Below is another mindmap around end point selection but it is traditional approach of cons/pros highlighted for each endpoint. Below map can also drive your discussion to selecting endpoint and relate it to customer’s use cases.


All these mindmaps will give you fair idea on what Endpoint selection. I must admit there might more factor which will influence your design but these are pretty big blocks to start with.

Mindmap for Horizon View Storage Design Considerations

I have come up with mindmap which explains what are various considerations and dependency in calculating VDI storage requirements. Please note it is in DRAFT and will continue to be updated as when I learn about storage. I’m using MindMaple product for mindmapping. I found it very easy to use and customize. Above all it is free to use. In the mind map below there are three major considerations for VDI Storage.


  1. Tier Type
  2. IOPS
  3. Storage Capacity


At first glance you might not see much but as I expand the map further you might feel it is making sense. Let’s start with IOPS first.


In IOPS we start with Types of application and number of application. E.g. If the application is graphics heavy it will need more IOPS. If application is a video recorder it would need more write IOPS. So we need to know what is the Read/Write ratio of these applications? Windows XP, Windows7, Window8 and Windows10 will differ in terms of IOPS requirements. All these parameters will influence RAID type which will further impact number of disks. IOPS will also get influenced by User profiles as shown with dotted arrow and it is most relevant when we don’t know IOPS requirement of applications which is generally the case.




Tier Type

In tier type, we might have to decide on whether to select SAS disk or SATA disk. Please note typical VDI Desktop is made of three different disk types

  1. Linked Clone Disk
  2. Persistent Disk (User Data Disk)
  3. Disposable Disk (temp and page file)
  4. Replica Disk

Linked clone disk might go on 15K/10K disk based on the application requirement e.g. for Autocad you will definitely need 15K disks. Therefore tiering will definitely have some inputs for IOPS. Similarly user profiles will drive persistent disks, non-persistent disks which will further influence IOPS.

Storage Capacity

Storage capacity has significant number of considerations and all are coming from desktop size. Desktop size needs decision on persistent desktop/non-persistent desktops. There is best practices maximum on number of VMs you can put per Datastore as per Ray’s blog. In non-persistent desktop your refresh interval drives the size. If you are refresh desktop at user logoff, then normal Linked clone size growth is consider only 10% of replica disk. Further, configured memory and reservation will have impact on Swap file and therefore on storage sizing. If you are looking for 3D support for your desktop, additional Swap file is created which will again impact the disk size. How much disk space you are considering for desktops. OS Type selection will also have impact on desktop size as memory and CPU requirement varies as per OS type which is shown using dotted arrow.After your desktop size is finalized, multiple that with number of desktops for storage capacity, add overhead which is normally 10% of total storage requirement. Using max VMs per Datastore you can calculate number of LUN size and size of each LUN.

Hope this helps you and I will continue with mindmaps in future blog posts

What to look before selecting VDI Pools

Following are various design aspects I have brain stormed which will allow to see which is better pool for your use case. Apparently my view is, you will need mix of both the pool.



Full Clone

Linked Clone



Medium. User need to wait for his VM to come up. Less than 15 mins. Replication of VM is must.

Medium. User need to re-login again, process will be initiate new desktop if non-persistent desktop is selected. Replication of  only user profiles is needed

High. Since it is server Farm. If one server goes down, user simple need to re-login again. Replication of 1 RDSH server and user profiles is needed


Need desktop management software for patching, updating. User profile management is not needed

Image management is simpler. Just manage Parent VM. User profile management will be done using UEM/Persona.

No Image management. Just ensure RDSH host are consistent in Size and application footprint **.

3rd party management software is needed for user profile management **.

No IP Address management. No DHCP server required


User login time is reduced. Heavy graphics users

User login time is might delayed unless SSD is used. For Task workers

User will always have to undergo login experience to RDSH hosts. For shift workers


For 100 desktop you need 100 license e.g. 100 AV licenses

For 100 desktop you need 100 license e.g. 100 AV licenses

You only license RDSH host be CALs or instance based.


No restriction.

Multimedia redirection. Audio/Video conference

No Multimedia redirection. No Audio/Video Conference. Very little scope for automation.**

Hope it helps the community, However this post is work in progress. I must say this post completely inspired from Scott Lowe (@Scott_Lowe) vSphere design training hosted on plural sight (@pluralsight). Other helpful posts (Post1, Post2)

Update (18th Oct, 2015): With view 6.2, Multimedia redirection, Audio/Video conferencing, Lync is supported. Persona management is supported. Difference between VDI desktop and RDSH desktop is decreasing rapidly. Now with 6.2 even 3D graphics is supported. Smart load balancing of RDSH host is also introduced in 6.2

VMware Horizon View Pools–Part02

Continuing from our previous post

User Assignment

Dedicated desktops

It is assigned to the individual. It means user gets same desktop every time she logs into view.

Use case for Dedicated desktops

It is recommended to have dedicated desktop if application cannot be published or it cannot be packaged. These application be could be user based license or might need huge memory/local storage. These users are primarily developers e.g. Visual Studio, Heavy graphics user e.g. AutoCAD, Photoshop, Google Earth

Floating desktops

This desktop is assigned for the duration of the session. After user logoffs, this desktop is available for other user. In floating pool, user will get different desktop every time he logs in, but experience do not change, thanks to Persona management.

Use cases for floating desktops

Highly recommended for shift workers where Business is operating round the clock, supports team are available round the clock. Also Manufacturing floor, library stores where multiple users will be using services randomly but will not be logged to the desktop permanently. It might appear to you now that you must enable logoff disconnected session immediately while configuring policy for floating desktop pools.

License saving : If you have 300 users working round the clock, you just purchase 100 VDI licenses. VDI is licensed for concurrent users.

Case for floating desktop becomes extremely weak if shift workers are just using one application e.g. a call center application and excel sheet. Both these applications can be easily published on RDSH host. Refer this post here which substantiates my claim

At this stage when you have made choice about types of pools and types of assignments, we still have choice whether to select stateless or stateful desktop. Point I wish to highlight, there no dependence on types of assignment you select on the state of desktop. Black & Yellow arrow below reiterates my point.


How do you make a desktop stateless? Every time you select linked clone deployment type you must make a decision on state of desktops.

vCenter Deployment

In vCenter we create a template for server deployment and this template is considered a Gold image. All server deployment happens through this gold template.

Full Clone

In full clone, full size of golden image is deployed. A like server deployment, this copy is unique copy. Only difference is template is based on Desktop OS. In VDI this golden image is referred as master image. Since it is full copy, same size of image is created. This leads to huge storage consumption.

Use cases for Full clone

These desktops are needed for heavy graphics users for storing large amount of files on desktops and sharing same files among colleagues.For users who wish to install customized software for testing e.g. developers.For software licenses which needs dedicated desktops. You could see there is strong relationship between dedicated desktops and Full Clone.

If you create a floating desktop you cannot create full clone desktop

Linked Clones

Linked clone desktops are delta copy of parent virtual machine. You cannot create a linked-clone pool from a virtual machine template, it is from powered off VM you create linked clone. Delta is difference between parent copy and linked clone desktop. Linked clone is assisted via view composer component which basically creates a replica of parent virtual machine and snapshot. All linked clone virtual machines are delta copies of replica virtual machines. This delta is extremely small compared to parent virtual machine size. However when you decide to make a dedicated desktop based on linked clone, your replica image becomes read only and all changes happen on OS level. With this comes an option of disposable storage and persistent storage. These options are not available in full cloned desktop pool settings.

Use cases for linked clones

Primarily to save storage cost. But as mentioned in previous post, xtremIO & Purestorage does this saving at array level.  There are other factors and use cases for linked clones which I will be discussing in up coming posts.


p style=”text-align: left” align=”justify”>Updated: 18th Oct, 2015

VMware Horizon View Pools

Its been quite a while I blogged. However during this big pause I learnt one thing about myself. I don’t publish unless I’m convinced information which I’m posting is not found or neatly explained. I have been always confused on persistent desktops, stateful desktops, stateless desktops, Full cloned, linked clone. I have only heard of linked clone, other terms are interchangeably used. This is post is aimed at clarifying these doubts.

Pools are basically collections of desktops. These desktop are either pre-created or can be created on the fly or can be created as demand increases.

Why we create pools?

Pool is like a group policy. If you define it once and it applies to group of users and computers. Similarly in pools you can defined various settings to control deployment of desktops, logoff action, provisioning style sysprep/quickprep.

Types of Pools

Automatic Pool

Desktops are automatically created. You can specify total number of virtual machines you wish pool to provision at any given time. With automatic pool you also have option to keep minimum number of VM to Spare for new users. This will allow you to control how frequently VMs should be provisioned, there by controlling load on the view composer/vCenter servers. Setting also ensures desktops are available for immediate use. Please note horizon view licenses are based on current users. Once you know the number of concurrent users, you can designed this parameter accordingly. If you are purchasing 1000 concurrent user licenses, then you should never put more than 1000 as maximum number of VM per pool.

Manual Pool

Manual is used when Desktop VM is already provisioned and available in vcenter. Or it is not managed by vCenter (e.g. Hyper-V, SCVMM) or it is physical desktop. Very limited use case.


It is terminal service now renamed by Microsoft as Remote Desktop Services (RDS).Primarily used to publish session based desktops and applications. However in RDSH pool, You can only create a session based desktops for users. Remember this is not pool of desktops. User can log into RDSH simultaneously. RDSH based desktop pools only supports Windows Based desktops. Again, very limited use case for desktops. In fact RDSH real power is to publish applications on RDSH servers and make it accessible from any device.

Decision on which one to use

Simplest way to select the type of pool is to find if you are using only view based VMs? If yes, answer is automated pool.

Are you going to use some 3rd party desktop management software and User profile management software? If answer is Yes, think of RDSH based pool.

Note: RDSH based pool do not support persona management. So decision is primarily around user profile management and operations. RDSH based desktops pools use case is very limited. Use cases which RDSH based desktop can solve are already covered and over lapping with Automated pool

1. Roaming profile management (Automated Pool)

2. Image management (Automated Pool)

3. Users don’t want to buy software licenses per desktop (RDSH Based Desktop)

e.g. MS Office, Windows OS license and other software products which support CAL types.

4. User must get same desktop every time he logs in (Automated Pool)

5. User need custom application installed on his desktop (Automated Pool)

# [4] RDSH you don’t have floating desktops or dedicated desktop pools.

What else users work profile would be? It is major driving factor to choose Automated over RDSH Pool.


In next post we discuss Types of Assignments and Types of Deployments how they further impact the pool selection type.