Determine the base image/template requirements for the design
Firstly and perhaps most obviously we need to have an understanding as to what OS levels we are going to be deploying and supporting with the View environment. Windows XP, Windows 7, Windows 8? Then what versions are we going to support, 32 bit or 64 bit.
Will we lock the desktop down and reduce some of the common performance grabbing features such as Aero themes, screen savers etc.
What is going to be installed locally in the desktop, any applications that cannot be delivered by an alternative method (ThinApp?). Perhaps we need a master image to span multiple countries or support mull-lingual users in which case do we need to install extra language packs into the image?
Establish replica requirements
Simply put, this should be placed on the tastes disk we have available to us. If we have flash brilliant, if not then the next highest tier is a must.
Ensure the replica does not reside on the same LUN as the linked clones as this will reduce performance.
Identify linked clone requirements (e.g, OS disk)
Each linked clone disk is small, starting at 16MB of space for each 2GB of disk. Remember they are sparse disks, so we only need to account for changed blocks. These will only tend to grow quickly with persistent desktops, so if we have a pool of power users that we know will be installing multiple applications then we need to be aware that their disks may grow quicker than anticipated.
When we use linked clones we are restricted to 8 host per cluster, therefore, we may need to place the linked clones in a separate cluster of their own. We should look to limit the number of VMs in a linked clone pool to 512 as the refresh and recompose events will create significant I/O. 512 is recommended and also the supported maximum.
We should also look to design a maximum of 128 linked clones per VMFS datastore. NFS can achieve up to 256 linked clones per datastore.
These numbers will all depend on the workload requirements. We should look to group VMs that are running similar workloads to be able to better monitor and predict performance.
Determine the amount of estimated data growth and the impact on the design
Data growth is tricky to estimate and depends on a number of factors related to the way the infrastructure is setup. For example, if you have a desktop pool for call centre users, they will more than likely be using a floating desktop. Their profiles could reside on a network share, and the applications could reside in a ThinApp repository. This use case is likely to have little to no growth.
Another example, could be a developer pool. They may well use persistent desktops, still with their profiles residing on a network share but with the ability to store data locally and the power to install applications to their desktop, growth is potentially likely to be high.
As users interact with linked-clone desktops, the OS disks will expand as write operations update file blocks. A desktop refresh operation restores the OS disks to their original state and size, thus reducing storage consumption. VMware therefore recommend to regularly refresh linked clones (preferably at logoff) to limit storage growth, especially when the storage overcommit level is set to aggressive. Worth noting here, that the refresh operation does NOT affect persistent disks. Ideally, pool settings should be configured to refresh the desktop at logout for both dedicated and floating pools.
Whilst it doesn’t directly lower storage consumption pay attention to the rebalance operation and the schedule it runs at. If an environment consists of large linked-clone pools and uses multiple data stores, the storage space may not be used efficiently. The rebalance option saves storage space on overloaded data stores and ensures that none are underused. Rebalancing also allows you to add new data stores to the capacity inventory and remove existing datastores.
Ensure disk space is monitored closely to ensure that you don’t experience any outages due to lack of space.
Establish persistent disk requirements
The persistent disk allows each dedicated assignment linked clone to store the user profile, settings and data. When using floating desktops, user specific data does not need to be preserved, sp persistent disks are not available.
Generally, in most ideal situations, the profile data will be stored centrally on a network and persistent disks will not be required, however in some cases where profile data may become very large, performance may be enhanced by attaching a persistent disk to a users desktop.
Power users are an ideal use case for a persistent disk, as they will likely be heavy application users and are likely to have the ability to install applications locally on their desktops.
You can store persistent disks on the same datastore as the OS disk or on a different datastore.
Establish disposable disk requirements
When you create a linked clone pool, you can configure a separate, non-persitent disk to store the guest OS’s paging and temp files that are generated during user sessions. When the linked clone is powered off, View Manager replaces the disposable disk with a copy of the original disk that View Composer created with the linked clone pool. Linked clones can increase in size as users interact with their desktops. Using disposable disks can save storage space by slowing the growth of linked clones. For design purposes, it is worth noting though, that the disposable disk is stored on the same dat store as the OS disk.
Determine full clone requirements
Full clones will probably have a limited use case within most VDI deployments. Primarily this will be because of the disk space they consume. Most task workers that do not have elevated permissions within their desktops to perform administrative tasks or install software in their desktop should have no requirement for a full clone. Whilst you can still provide linked clone desktops with the ability to install software locally, you run the risk of loosing this data of a refresh or recompose action is performed on that pool.
Full clone desktops should be used for persistent desktops that will require some sort of DR. I say this because you cannot replicate a linked clone desktop to another site using such services such as SRM. If the desktop was a full clone, it could be replicated an imported into another View Manager in a DR site.
Establish persona requirements (e.g, central profile store, View Virtual Profiles, etc)
Refer back to Objective 3.1 and review the requirements for the virtual profile repository again. This covers off some of the requirements for creating the profile repository. Sizing the profile repository is crucial for success.
For the exam especially, remember you need a View Premier licence to enable and use View persona Management.
If deploying ThinApp’s to the desktop, the ThinApp sandbox can be included in the users profile.
If supporting multiple OS’s remember that Windows XP uses v1 profiles, where as Vista and Win7 use v2. Users cannot access the same profile if switching between desktops that use different profile versions.
Utilise GPO to add the View Persona Management (ADM) template (ViewPM.adm) ready for configuration and deployment. You are able to embed this in the local computer policy not he template or parent VM, but this is not going to work particularly well when changes need to be made, without re-composing existing desktops.