Storage Overview

Storage Overview

Storage Repositories (SRs)

XenServer defines a container called a storage repository (SR) to describe a particular storage target, in which Virtual Disk Images (VDIs) are stored. A VDI is a disk abstraction which contains the contents of a virtual disk.

VDIs to be supported on a large number of SR types. The XenServer SR is very flexible, with built-in support for IDE, SATA, SCSI and SAS drives locally connected, and iSCSI, NFS, SAS and Fibre Channel remotely connected. The SR and VDI abstractions allow advanced storage features such as Thin Provisioning, VDI snapshots, and fast cloning to be exposed on storage targets that support them. For storage subsystems that do not inherently support advanced operations directly, a software stack is provided based on Microsoft's Virtual Hard Disk (VHD) specification which implements these features.

Each XenServer host can use multiple SRs and different SR types simultaneously. These SRs can be shared between hosts or dedicated to particular hosts. Shared storage is pooled between multiple hosts within a defined resource pool. A shared SR must be network accessible to each host. All hosts in a single resource pool must have at least one shared SR in common. 

SRs are storage targets containing virtual disk images (VDIs). SR commands provide operations for creating, destroying, resizing, cloning, connecting and discovering the individual VDIs that they contain.

A storage repository is a persistent, on-disk data structure. For SR types that use an underlying block device, the process of creating a new SR involves erasing any existing data on the specified storage target. Other storage types such as NFS, Integrated StorageLink (iSL) SRs, create a new container on the storage array in parallel to existing SRs.

Virtual Disk Images (VDIs)

Virtual Disk Images (VDI) are a storage abstraction that are presented to a VM representing the physical disk. VDIs are the fundamental unit of virtualized storage in XenServer. Similar to SRs, VDIs are persistent, on disk objects that exist independently of XenServer hosts. CLI operations to manage VDIs are described in Section A.4.24, “VDI Commands”. The actual on-disk representation of the data differs by the SR type and is managed by a separate storage plug-in interface for each SR, called the SM API.

Physical Block Devices (PBDs)

Physical Block Devices represent the interface between a physical server and an attached SR. PBDs are connector objects that allow a given SR to be mapped to a XenServer host. PBDs store the device configuration fields that are used to connect to and interact with a given storage target. For example, NFS device configuration includes the IP address of the NFS server and the associated path that the XenServer host mounts. PBD objects manage the run-time attachment of a given SR to a given XenServer host.

Virtual Block Devices (VBDs)

Virtual Block Devices are connector objects (similar to the PBD described above) that allows mappings between VDIs and VMs. In addition to providing a mechanism for attaching (also called plugging) a VDI into a VM, VBDs allow for the fine-tuning of parameters regarding QoS (quality of service), statistics, and the bootability of a given VDI.

Summary of Storage objects

The following image is a summary of how the storage objects presented so far are related:

Virtual Disk Data Formats

In general, there are three types of mapping of physical storage to a VDI:

1. Logical Volume-based VHD on a LUN; The default XenServer blockdevice-based storage inserts a Logical Volume manager on a disk, either a locally attached device (LVM type SR) or a SAN attached LUN over either Fibre Channel (LVMoHBA type SR), iSCSI (LVMoISCSI type SR) or SAS (LVMoHBA type Sr). VDIs are represented as volumes within the Volume manager and stored in VHD format to allow thin provisioning of reference nodes on snapshot and clone.

2. File-based VHD on a filesystem; VM images are stored as thin-provisioned VHD format files on either a local non-shared filesystem (EXT type SR) or a shared NFS target (NFS type SR)

3. LUN per VDI; LUNs are directly mapped to VMs as VDIs by SR types that provide an array specific plug in (NetApp, EqualLogic or StorageLink type SRs). The array storage abstraction therefore matches the VDI storage abstraction for environments that manage storage provisioning at an array level.

VDI Types

In general, VHD format VDIs will be created. You can opt to use raw at the time you create the VDI; this can only be done using the xe CLI. .

To check if a VDI was created with type=raw, check its sm-config map. The sr-param-list and vdi param-list xe commands can be used respectively for this purpose.

Creating a Raw Virtual Disk Using the xe CLI

1. Run the following command to create a VDI given the UUID of the SR you want to place the virtual disk in:

xe vdi-create sr-uuid=<sr-uuid> type=user virtual-size=<virtual-size> \

name-label=<VDI name> sm-config:type=raw

2. Attach the new virtual disk to a VM and use your normal disk tools within the VM to partition and format, or otherwise make use of the new disk. You can use the vbd-create command to create a new VBD to map the virtual disk into your VM.

Converting Between VDI Formats

It is not possible to do a direct conversion between the raw and VHD formats. Instead, you can create a new VDI (either raw, as described above, or VHD) and then copy data into it from an existing volume. Citrix recommends that you use the xe CLI to ensure that the new VDI has a virtual size at least as big as the VDI you are copying from (by checking its virtual-size field, for example by using the vdi-param-list command). You can then attach this new VDI to a VM and use your preferred tool within the VM (standard disk management tools in Windows, or the dd command in Linux) to do a direct block-copy of the data. If the new volume is a VHD volume, it is important to use a tool that can avoid writing empty sectors to the disk so that space is used optimally in the underlying storage repository — in this case a file-based copy approach may be more suitable.

VHD-based VDIs

VHD files may be chained, allowing two VDIs to share common data. In cases where a VHD-backed VM is cloned, the resulting VMs share the common on-disk data at the time of cloning. Each proceeds to make its own changes in an isolated copy-on-write (CoW) version of the VDI. This feature allows VHD-based VMs to be quickly cloned from templates, facilitating very fast provisioning and deployment of new VMs.

This leads to a situation where trees of chained VDIs are created over time as VMs and their associated VDIs get cloned. When one of the VDIs in a chain is deleted, XenServer rationalizes the other VDIs in the chain to remove unnecessary VDIs. This coalescing process runs asynchronously. The amount of disk space reclaimed and the time taken to perform the process depends on the size of the VDI and the amount of shared data. Only one coalescing process will ever be active for an SR. This process thread runs on the SR master host.

If you have critical VMs running on the master server of the pool and experience occasional slow IO due to this process, you can take steps to mitigate against this:

• Migrate the VM to a host other than the SR master

• Set the disk IO priority to a higher level, and adjust the scheduler. See Section 5.5.9, “Virtual Disk QoS Settings” for more information.

The VHD format used by LVM-based and File-based SR types in XenServer uses Thin Provisioning. The image file is automatically extended in 2MB chunks as the VM writes data into the disk. For File-based VHD, this has the considerable benefit that VM image files take up only as much space on the physical storage as required. With LVM-based VHD the underlying logical volume container must be sized to the virtual size of the VDI, however unused space on the underlying CoW instance disk is reclaimed when a snapshot or clone occurs. The difference between the two behaviors can be characterized in the following way:

• For LVM-based VHDs, the difference disk nodes within the chain consume only as much data as has been written to disk but the leaf nodes (VDI clones) remain fully inflated to the virtual size of the disk. Snapshot leaf nodes (VDI snapshots) remain deflated when not in use and can be attached Read-only to preserve the deflated allocation. Snapshot nodes that are attached Read-Write will be fully inflated on attach, and deflated on detach.

• For file-based VHDs, all nodes consume only as much data as has been written, and the leaf node files grow to accommodate data as it is actively written. If a 100GB VDI is allocated for a new VM and an OS is installed, the VDI file will physically be only the size of the OS data that has been written to the disk, plus some minor metadata overhead.

When cloning VMs based on a single VHD template, each child VM forms a chain where new changes are written to the new VM, and old blocks are directly read from the parent template. If the new VM was converted into a further template and more VMs cloned, then the resulting chain will result in degraded performance. XenServer supports a maximum chain length of 30, but it is generally not recommended that you approach this limit without good reason. If in doubt, "copy" the VM using XenCenter or use the vm-copy command, which resets the chain length back to 0.

Personal vDisk

Personal vDisk

Unlike traditional VDI deployments involving pooled desktops, where users lose their customizations and personal applications when the administrator alters the base VM, deployments using personal vDisks retain those changes. This means administrators can easily and centrally manage their base VMs while providing users with a customized and personalized desktop experience. Personal vDisks provide this separation by redirecting all changes made on a user’s VM to a separate disk (the personal vDisk). The content of the personal vDisk is blended at runtime with the content from the base VM to provide a unified experience. In this way, users can still access applications provisioned by their administrator in the base VM.

Personal vDisks can be used with Provisioning Services or Machine Creation Services. Generally, the use of personal vDisks is evaluated when user groups require the ability to personalize their virtual desktop. This could include a need to use a variety of departmental applications or general personalization that is beyond what is available in the user profile. However, there is no defined limitation of Citrix personal vDisk technology to these specific use cases. It is entirely possible to utilize personal vDisks in scenarios that may not maximize flexibility or virtual desktop density, yet are entirely appropriate to the enterprise environment.

The need and use of personal vDisk technology must align with the personalization characteristics of the user group captured during the assess phase as well as the FlexCast model selected.

Note: Citrix personal vDisk technology loads a set of Kernel mode drivers very early in the Windows boot process. By and large, these Phase 1 drivers allow most applications to work in a seamless manner with a personal vDisk attached. Exceptions to this are applications that operate or install components prior to the loading of the Citrix personal vDisk drivers. Specifically, certain device driver installers or antivirus software may not work properly if installed within the personal vDisk.

Decision: Size

While many factors play a part in deciding the size of a Personal vDisk, there are certain basic requirements that should be followed:

• Minimum size – 3GB
• Maximum size – Undefined

Note: The Personal vDisk can be expanded but cannot be shrunk.
Beyond system requirements, the following major factors influence what size to allocate for a user’s Personal vDisk:

• Anticipated growth – Most organizations should size personal vDisks well above the minimum requirement of 3GB and should factor in each user group’s workload requirement. As a general rule of thumb, the following recommendations provide a good starting point:

Light user – 7GB
Medium user – 10GB
Heavy user – 15GB

• Storage technologies – The use of storage technologies such as thin provisioning and de-duplication can significantly reduce storage requirements for personal vDisks allowing larger sizes to be specified:

Thin provisioning – Administrator can use thin provisioning to present more storage space to the virtual machines than is actually available on the storage repository. De-duplication – Storage requirements may be reduced through the use of data de-duplication, whereby duplicate data is replaced with pointers to a single copy of the original item.

• Folder redirection or cloud data service – In many smaller environments, utilizing personal vDisk as a profile management solution is common. However, the limitations present in distributed profiles quickly present themselves when this option is selected. The first step many organizations utilize towards a robust profile solution is to utilize Microsoft special folder redirection in order to redirect user data to a network share.

Other organizations employ a cloud based data service such as Citrix ShareFile. Personal vDisks can co-exist with either of these deployment options. Depending on the implementation mechanism, the presence of either of these technologies can significantly reduce the initial sizing of personal vDisks for users.

Experience from the Field

Citrix – Analysis of Citrix’s internal deployment of XenDesktop virtual desktops featuring personal vDisk reveal that most vDisks are utilized at a rate of 36.74%. The average size of a PvD is initially 10 GB and has only been expanded for a small number of power users. This size includes user profiles as well as any data, applications and other aspects accumulated in the course of eight months of usage. In this environment that is *NOT* utilizing a profile management solution or roaming profiles, vDisks populate a few GB up front with user profile data then are slowly accreting changes up to the aforementioned level over time.

Receiver Selection

Receiver Selection

Citrix Receiver is an easy-to-install software client that provides access to applications, desktops and data easily and securely from any device, including smartphones, tablets, PCs and Macs.

The following section provides a series of design decisions that should be considered when deploying Citrix Receiver.

Decision: Receiver Type

While most organizations should simply deploy the latest Citrix Receiver compatible with their endpoint, it is important to recognize that there are certain differences between editions. The following table should be referenced to determine the most appropriate edition of Citrix Receiver for each user group. For the latest feature matrix, please refer to CTX104182 – Receiver - Client Feature

Matrix.

Decision: Initial Deployment

There are several deployment options available for delivering Citrix Receiver to an endpoint. Although it is usually a best practice to have a full version of Citrix Receiver deployed to an endpoint to provide the greatest level of functionality, it is important to consider fallback options such as the Java Client and the HTML5 Receiver for those situations where an installation of Citrix Receiver is simply not possible.

Experience from the Field

Furniture distributor – A furniture distributor maintains a configurator application for various furniture options. The configurator application is accessed via a limited functionality kiosk that is deployed at various furniture outlets, including small, independent retailers with little to no IT staff present. The kiosks are completely locked down in many situations, to the point where even the running of Java applications is limited. The kiosks do feature a modern browser (Google Chrome), and therefore, are able to utilize the HTML5 Receiver in order to provide access to the configurator application.

County government – A government IT organization provides services to all agencies operating in the county. A mixture of full desktops are applications are deployed to both Windows based desktops and iPads. Since the desktops are joined to the Active Directory domain, GPOs are utilized to deploy and configure Citrix Receiver. Mobile users accessing the Citrix environment via an iPad install and configure Receiver from the App Store. To allow for seamless provisioning, e-mail based discovery was configured. This allows users to configure Receiver for both internal and external access through NetScaler Gateway by entering in their e-mail address.

The following mechanisms are commonly used to deploy and update Citrix Receiver:

• StoreFront – If Citrix StoreFront is available, administrators can deploy Citrix Receiver via a Receiver for Web site. When deployed, a Receiver for Web site enables users to access StoreFront stores through a web page. If the Receiver for Web site detects that a user does not have a compatible version of  Citrix Receiver, the user is prompted to download and install Citrix Receiver.

• Internal download site – Users may be prevented from downloading software from the Internet, even if they have permission to install applications. Administrators can create an internal website for supported Citrix Receivers. Templates for such a site are available from the Citrix Downloads site. When a user accesses a deployed site, it will detect the operating system on the user’s device and guide the user to a local Citrix Receiver install suitable for their device.

• Windows store – The Citrix Receiver for Windows 8/RT is available from the Windows 8 store. This Receiver is available for ARM or Intel based Windows 8/RT devices only. It supports native Windows 8 style and gestures.

• Mobile device – Many mobile devices have unique methods of deploying applications. It simply may not be possible to deploy Citrix Receiver via traditional methods, therefore the following options are most likely to be selected for mobile devices:

Markets and stores – The latest supported Citrix Receiver is available for Android and iOS on the deployment portal of choice for these platforms. For Android devices version 2.2 and higher, this will be the Android Play platform. For iOS devices, this will be the Apple Store. Other mobile deployment methods – Many mobile platforms offer proprietary methods of deploying software. For example, it is possible to utilize BlackBerry Enterprise Server to deploy the BlackBerry Citrix Receiver 2.2 to supported devices.

• Master image – Most organizations support a limited number of master desktop images, which are deployed to each business owned desktop, laptop, server, or virtual desktop. A common mechanism to ensure access to virtual desktops and applications is to include a supported version of Citrix Receiver in the master image. Subsequent updates to Citrix Receiver are handled either by utilizing the Citrix Receiver updater plug-in and Merchandising Server, enterprise software deployment tools, or manually.

• Enterprise software deployment – Many organizations employ an enterprise software deployment (ESD) tool. ESD tools can be used to deploy Citrix Receiver to managed endpoints. ESD tools cannot be used to deploy Citrix Receiver to unmanaged endpoints, such as employee owned or partner devices.

• Group policy – Deploy and configure Citrix Receiver via Microsoft Group Policy. Sample start-up scripts that deploy and remove Citrix Receiver and Receiver Enterprise are available on Citrix XenApp and XenDesktop media: Citrix Receiver and Plugins\Windows\Receiver\Startup_Logon_

Scripts

• Manual install – All supported versions of Citrix Receiver are available from the Citrix Receiver Download site. Upon landing on this site, client detection is performed and a platform and operating system specific link is provided to allow users to download an appropriate edition of Citrix Receiver. It is important to note that no configuration will be accomplished via this download, so email based discovery will need to be performed. This option is likely to be utilized in a BYOD environment.

• Merchandising Server – Citrix Merchandising Server can be used to deploy Citrix Receiver. In addition, Merchandising Server can be configured to update Citrix Receiver and all supported plug-ins, or a sub-set depending on the needs of an organization. To achieve this, Merchandising Server periodically communicates with the Citrix update service, which maintains a list of components and their updates. Merchandising Server is not recommended as a long-term solution because it will reach

end of maintenance in August 2014 and end of life in August 2015. For more information, please refer to the Citrix support article – Lifestyle Milestones for Citrix XenDesktop.

Selecting the appropriate deployment method is based on the type of Citrix Receiver selected. The table on the next page should be referenced to help identify the appropriate deployment options for

Citrix Receiver.

Project Management

Project Management

Roadmap

Most companies don’t have sufficient time or resources to migrate every user group in one go. As such, it is important that the user groups identified are prioritized so that the business receives the

maximum value from their investment as soon as possible. To achieve this, you need to compare the business impact and time to value of each group:

• Business impact – Consider the impact that desktop virtualization will have on each user group and rank them accordingly. It is important that you double back here, and use the business drivers identified at the start of the project to make sure that you assign an appropriate ranking. Don’t just assign ratings based on how highly the business values each user group; instead focus on which user groups offer the most benefit to the company after virtualization. It’s a subtle but important difference.

• Time to value – For each user group, estimate how long it will take to implement the chosen FlexCast model based on the findings from the Capabilities Assessment. For example, you might find that a company already has a XenDesktop solution that can be leveraged to support those user groups that require a hosted VDI desktop resulting in a low time to value. Alternatively, the business might have no prior experience with XenClient resulting in a longer time to value. Compare application sets, user requirements and user numbers when differentiating between user groups that have been assigned the same FlexCast model. 

Note: If there are limited skills available in-house to implement a chosen FlexCast model, consider hiring external resources so that Time to Value can be reduced for the associated user groups.

Representing this information in a graph provides an easy way to visualize the results:

When it comes to assigning the implementation order, start from the top left hand corner of the chart and work your way to the bottom right hand corner. This way you start with some quick wins that offer a high-level of value to the company.

Once the project roadmap has been created, update the project plan so that it incorporates the prioritized roadmap.

Experience from the Field

Utility company – A large utility company realized that there would be a long time to value for user groups that had been assigned with a hosted VDI FlexCast mode, because they had no prior experience or training with this technology. To address this concern, the utility company engaged with Citrix Consulting who provided Consultants with previous experience of successfully deploying XenDesktop.

Build the Right Team

Desktop virtualization is a fundamental change that requires close collaboration between various business and technical teams in order to be successful. For example, the virtualization and desktop

teams need to work together to ensure that the virtual desktop image meets user needs while also being optimized for the datacenter. Failure to build a cohesive project team that consists of the right roles and skill sets can negatively impact performance, availability, user experience and supportability while also increasing costs and risk.

The following tables identify the business and technical roles required during an enterprise virtual desktop deployment. Although the list may seem quite large, many of these roles are only required

for a short time and multiple roles may be performed by a single person. The project manager and Citrix Architect are considered  to be full time roles with other team members being brought in only

when required. The project manager role is key to ensuring that the right people are involved in the project at the right time.

Design Overview

Designing a desktop virtualization solution is simply a matter of following a proven process and aligning technical decisions with organizational and user requirements. Without the standardized

and proven process, architects tend to randomly jump from topic to topic, which leads to confusion and mistakes. The recommended approach focuses on working through five distinct layers:

The top three layers are designed for each user group independently, which were identified during the user segmentation section of the assess phase. These layers define the user’s virtual desktop and how users access their desktop. Upon completion of these three layers, the foundational layers (control and hardware) are designed for the entire solution. This process guides the design thinking in that decisions made higher up impact lower level design decisions.

Link Apps to Users

Link Apps to Users

Once the application rationalization process is complete, use the results from the data capture process to identify which applications will be required by each user group. The following characteristics should be identified for each application so that the right application delivery model can be selected during the design phase of the project:

• Workload (T) – Collecting application workload requirements will allow the virtualization infrastructure to be sized and an appropriate application delivery model to be selected. For example, resource intensive applications will not be delivered via a Hosted Shared Desktop because there is limited control over how the resources are shared between users. There are two classifications available in the user assessment worksheet:

• Technically challenging (B) – An application should be classified as technically challenging if it is complex to set up, has extensive dependencies on other applications or requires a specialized configuration, for example an Electronic Medical Records (EMR) application. Technically challenging applications need to be identified during the application assessment because they are not generally appropriate for installation in to a base desktop image or delivery by application streaming. Delivering technically challenging applications as published applications will help to reduce the complexity of the base desktop image.

• Works offline (B) – Some user groups may require the ability to work offline. If so, it is important that the design can determine which applications will work without a network connection and which ones will not. Applications that require backend infrastructure such as web and database servers are not typically available offline.

• Peripheral connectivity (T) – If applications require connectivity with peripheral devices, identify the interface required so that it can be made available to the application when it is run from a virtual session.

Note: Generic USB redirection is now supported in Hosted Shared Desktops delivered through XenApp 7.6. XenApp and XenDesktop 7.6 are also USB 3.0 ready. A future release of Citrix

Receiver for Windows and Linux will include automatic device mapping and plug-and-play capabilities for USB 3.0 devices.

Note: USB redirection works for XenApp and XenDesktop 7.6 and above. For more information please refer to Citrix eDocs – USB and client drive considerations.

• Restricted access (B) – Application access may need to be restricted due to insufficient licenses / resources and to protect sensitive data / tools. For example, applications with a limited number of licenses should not be installed in to a base image that is shared with unlicensed users. There are three restricted access categories in the application assessment workbook:

Assign FlexCast Models

Assign FlexCast Models

As with physical desktops, it is not possible to meet every user requirement with a single virtual desktop type. Different types of users need different types of desktops. Some users may require

simplicity and standardization, while others may require high levels of performance and personalization. Implementing a single desktop virtualization model across an entire organization will inevitably lead to user frustration and reduced productivity.

Citrix FlexCast offers a complete set of application and desktop virtualization technologies that have been combined into a single integrated solution. Because each FlexCast model has different advantages and disadvantages, it is important that the right model is chosen for each user group within the organization.

There are five FlexCast models available, the advantages and disadvantages of each model are described below:

• Hosted shared – With the hosted shared FlexCast model, multiple user desktops are hosted on a single server-based operating system and provisioned using Machine Creation Services or Provisioning Services. The hosted shared desktop model provides a low-cost, high-density solution, however applications must be compatible with a multi-user server based operating system. In addition, because multiple users are sharing a single operating system, users are restricted from

performing actions that negatively affect other users, for example installing applications, changing system settings and restarting the operating system. There is also the potential that a single user could consume an unfair share of resources, which may negatively affect other users. The hosted shared FlexCast model is provided by Citrix XenDesktop in combination with Microsoft Remote Desktop Services (RDS).

• Hosted VDI – The hosted VDI FlexCast model provides each user with a desktop operating system. Hosted VDI desktops are less scalable than hosted shared desktops because each user requires their own operating system. However, hosted VDI desktops remove the requirement that applications must be multi-user aware and support server based operating systems. In addition, the hosted VDI model provides administrators with a granular level of control over the number of virtual processors and memory assigned to each desktop. The hosted VDI model is provided by Citrix XenDesktop, and offers the following sub categories:

Random / Non-Persistent – Desktops are based on a single master image and provisioned using Machine Creation Services or Provisioning Services. Users are dynamically connected to one of the desktops in the pool each time they logon. Changes to the desktop image are lost upon reboot.

Static / Non-Persistent – Desktops are based on a single master image and provisioned using Machine Creation Services or Provisioning Services. Users are allocated a virtual desktop on first access. Once assigned, users will always be connected to the same virtual desktop. Changes to the

desktop image are lost upon reboot.

Static Persistent – Desktops are based on a single master image and provisioned using Machine Creation Services or Provisioning Services. Users are allocated a virtual desktop on first access. Once assigned, users will always be connected to the same virtual desktop. Changes to the desktop are

stored in a personal vDisk and retained between reboots. Desktops with a personal vDisk cannot be shared between multiple users; each user requires their own desktop. If high availability is required, the personal vDisk must be stored on shared storage.

• Remote PC – Physical desktops that have already been deployed. These desktops must be managed manually or with 3rd party desktop management tools.

• Streamed VHD – Desktops are based on a single master image and provisioned using Provisioning Services. The streamed VHD FlexCast model allows Windows XP, 7 and 8 desktops to be run locally on the user’s desktop computer. Streamed VHD is a great solution for high-end workstations because it allows them to leverage local processing power. Streamed VHD requires a LAN connection to be in place between the desktop and the provisioning servers and changes to the desktops are lost upon

reboot.

• Local VM – Windows XP, 7, and 8 desktops running locally within a hypervisor. The virtual desktop image is completely delivered to the hypervisor to allow for offline connectivity. Citrix XenClient is used to provide the Local VM FlexCast model.

• On demand apps – The On-Demand Apps FlexCast model does not provide users with a virtual desktop; instead Windows applications are centralized in the datacenter, and instantly delivered via a high-speed protocol (requires connection) or streamed (offline support) via Microsoft App-V.

FlexCast Model Comparison

Each user group in the User Segmentation worksheet should be compared against the following table to determine which FlexCast Model should be assigned. Ensure that you update the FlexCast

value for each user group in the worksheet.

Note: Any FlexCast decisions need to factor in latency. Please see the Latency section of the Design Phase.

Define the User Groups

Define the User Groups

Once the data capture is complete, you’re ready to start dividing up the users into different groups based on a common set of requirements. This allows a FlexCast model to be assigned to each user group without compromising on performance or functionality.

User Segmentation

Users are often classified as task workers, branch office workers, mobile workers and the like. Unfortunately, this classification is too broad to offer meaningful segmentation because users can

simultaneously be described as task workers, mobile workers, and branch office workers. Instead, group users together that have the same requirement for:

• Primary datacenter (B) – Each user will have a primary datacenter assigned that will be used to host their virtual desktop, data, and application servers. Identify the datacenter that the user should be assigned to rather than the datacenter they are currently using. Users will be grouped based on their

primary datacenter so that a unique design can be created for each one.

• Personalization (B) – Personalization requirements are used to help determine the appropriate FlexCast model for each user group. For example, if a user group requires complete personalization, a Hosted VDI desktop with Personal vDisk will be recommended as the optimal solution. There are three classifications available:

• Security (B) – Security requirements are used to help determine the appropriate FlexCast model and policies for each user group. For example, if a user group requires high security, a Hosted-

Shared Desktop, Pooled Desktop or On-Demand Apps FlexCast model will be recommended as the optimal solution. There are four classifications available:

• Mobility (B) – Mobility requirements are used to help determine the appropriate FlexCast model for each user group. For example, if a user group sometimes connects remotely, the Streamed VHD FlexCast model will not be selected because it requires a high-speed local network. There are four

classifications available:

• Desktop Loss Criticality (B) – Criticality will be used to determine the level of high availability, load balancing and fault tolerance measures required. There are three classifications available:

• Workload (T) – Collecting user performance requirements will allow the desktop virtualization infrastructure to be accurately sized and an appropriate FlexCast model to be selected.

Note: Performance thresholds are not identified based on processor, memory or disk utilization because these characteristics will change dramatically following the application rationalization and desktop optimization process. In addition, it is likely that the user’s management tools and operating system will change during the migration process. Instead, workload is gauged based on the number and type of applications the user runs.

(T) Technical Characteristic

(B) Business Characteristic

Experience from the Field

Utility company – A large utility company collected data on every user in their organization. During the user segmentation process it was realized that the organization’s existing role definitions were

sufficiently well defined that all the users within a role shared the same requirements. This allowed a significant amount of time to be saved by reviewing a select number of users per group. 

Government – A government organization discovered that there was significant deviation between user requirements within each role, particularly around security and criticality. As such, each user

needed to be carefully reviewed to ensure that they were grouped appropriately.

The fastest and easiest way to identify your user groups within the user assessment workbook is to filter the results based on these key requirements. Once you have identified the users within one group, transfer the relevant information to the user segmentation worksheet within the assess spreadsheet.

Comparison of Data Capture Strategies

Comparison of Data Capture Strategies

Although the automated method is accurate, fast, and does not inconvenience employees, there are a number of business characteristics that automated tools cannot identify. For example, what is the criticality of the user, will the user need to work offline and should access to the application be restricted due to security or licensing restrictions? Therefore, the recommended approach is to

use the automated method to identify technical characteristics and a questionnaire to identify the business characteristics. 

The User Segmentation and Link Apps to Users sections provide detailed information on the user and application characteristics that you will need to collect. 

Key results from the user data gathering exercise should be documented in the assess spreadsheet.

Citrix Consulting Tips for Success

1. Representative users – If you don’t have enough time, resources, or licenses to inventory every desktop in your organization, make sure that you pick a representative subset of users. For example, deploying an agent on every desktop in the HR department but missing out the sales and finance

departments will impact your results. Take time to ensure that you select a representative subset of users from every department and role within the organization. And remember, not all users within a single department will have the same requirements.

2. Check the data – When using an automated inventory tool, regularly check that the data has been successfully uploaded to the central database. There have been cases reported where insufficient space has been allocated to the central database resulting in several weeks of agent data being lost causing the project to be delayed.

3. Monitoring period – It is extremely important that the automated inventory tool monitors the desktops over a sufficient period of time. At the very least, monitor the desktops for a minimum of

one month; ideally monitor usage over periods of peak activity such as quarter end so that you have a good idea of average and peak application performance requirements. There may be situations where users only need access to a specific application during quarter end and unless you are running the automated inventory tool at this time you will not be aware of its usage.

4. Remember the plugins – Plugins are available for various applications, including Microsoft Internet Explorer, Microsoft Word and Microsoft Outlook. For example Citrix ShareFile and e-mail archiving solutions are frequently implemented as plugins. To prevent critical functionality being omitted, plugins should be treated as applications during the application assessment.

5. Application dependencies – It is imperative that you understand all of the interactions between your applications. For example, there may be an application which requires Microsoft Word and

Excel be installed on the same system so that reports can be viewed. When it comes to the design phase of the project you will need to make sure that these applications are grouped together

appropriately.

6. Application consolidation – It may be tempting to skip through the application consolidation phase of the assessment, but time spent reducing the number of applications significantly reduces

complexity and time spent on the assessment and design phases of the project.

7. Application owners – To ensure that you don’t incorrectly categorize applications or remove an important application from your inventory, work closely with the various application owners during the Rationalization, Characteristics and Compatibility Steps.

8. Final check – Once the consolidated list of applications has been finalized, complete with characteristics and compatibility information it should be sent to the application owners for review to ensure that it is correct and no critical applications or information has been omitted.

Assess Overview

Assess Overview

Creating a desktop virtualization solution begins with a proper assessment. Architects that fail to properly assess the current environment find that they require the assess information later on, forcing them to backtrack, which can potentially stall and put the project at risk. 

By gathering all of the information from the outset, the architect will gain an appreciation for the current environment and be able to work from the beginning on properly aligning business and user requirements with the overall solution.

The assess phase is a five-step, simple to follow process:

1 - Define Organization

2 - Assess Environment

3 - Define User Groups

4 - Define Applications

5 - Plan Project

Step 1: Define the Organization

The first step in your virtual desktop project should be to understand and prioritize the strategic imperatives of the organization. This enables the project management team to define success criteria

and allows the design team to create a tailored and optimized architecture. 

Requirements can be captured during meetings or by distributing questionnaires. Meetings are more time consuming, but allow for follow-up questions to be asked and help to simplify the prioritization process. It is important that this exercise be completed jointly by both business managers and IT decision makers since both groups will have significantly different viewpoints. Take thefollowing examples of what certain organizations faced, which drove their selection of desktop virtualization.

Experience from the Field

Finance – A large financial institution had a base of operations in the city designated as the host city for an upcoming G8 summit. As these types of meetings historically include riots, protests and other

issues that can disrupt business and the safety of their employees, the financial organization needed an alternative allowing their users to work from the safety of their homes. 

Agriculture – Due to thin margins, an agriculture organization wanted to save money by extending the life of desktop PCs while still being able to run the latest applications. 

Healthcare – A large healthcare organization was in need of a solution to simplify application updates as the main application required updates on a weekly basis. Due to the distributed nature of the endpoint devices, the organization was in need of a better application delivery solution. 

These are just a few examples, but they demonstrate how organizations think about their priorities. Most organizations do not focus on technology, they focus on the needs of the user and of the organization. These needs can be met with technical solutions but it is imperative the team understands the “Why” of the project. 

In addition to the three real-world examples, the table on the next page identifies a few other priorities often stated from many organizations 

The prioritization process should be completed in collaboration with the project team, business managers and IT managers so that all views are considered. 

Early on, organizations often need to estimate the hardware required to support the new solution. Citrix Project Accelerator provides a fast and accurate way to estimate hardware and storage requirements: