With desktop virtualization you might be thinking what should I use to store all my desktops and data.  This can be especially confusing with Provisioning Server offering storage savings as well as storage optimization features from storage vendors.  This blog covers storage requirements for the various components of XenDesktop, storage for pooled vs. assigned desktops, and storage features from storage vendors that can be leveraged in XenDesktop.  XenDesktop Enterprise includes the Desktop Delivery Controller (Connection Broker), XenServer, Provisioning Server and XenApp for Virtual Desktops.

For a XenDesktop environment you will need storage space in the follow areas.

1. XenServer VM hard disks -  When you create your infrastructure VMs such as the DDC and any assigned / dedicated desktops you will need storage space for the virtual hard disks for these VMs.
2. User profiles and data -  For user customization you will store the user profiles on your storage device.  For those users you will also want to map a location to a network share for each user.  This is to store user data such as documents and spreadsheets.
3. Provisioning Server (PVS) vDisks - With PVS you can create a base vDisk image that is shared across hundreds of virtual desktops.  You will need space to store the base vDisk images along with multiple version of each image.
4. Provisioning Server write back cache files -  You will also need to store the write back cache for each virtual desktop.  The write back cache is used to store the changes to each desktop since the base vDisk image is read-only.  The write back cache file can be stored in the same location as the base PVS vDisk images or on a virtual hard disk for each virtual desktop VM.
5. Databases for XenDesktop components -  The Desktop Delivery Controller, XenApp for Virtual Desktops, and Provisioning Server (5.0) all offer the option to store the database on a separate database server for performance and redundancy.
6. Application streaming cab files for XenApp - With XenApp for Virtual Desktops you can stream the application on-demand directly to an isolation environment on the user's virtual desktop.  These files can be accessed via a UNC share or via HTTP(S). 

Storage for Pooled vs. Assigned desktops

When creating groups of virtual desktops you have a choice of either a pooled / shared group of desktops or assigned / dedicated desktops.  A pooled desktop groups allows a user to use any desktop in the pool.  This allows for instant access to the virtual desktop since you can have an idle pool of desktops and simplified management by only needing to patch and update the base image instead of each individual dedicated desktop.  When a user logs off the desktop is returned to the pool.

An assigned / dedicated desktop has a few feature advantages since the user has full control over the desktop.  One example is the support for user installed applications in their virtual desktop.  Over time Citrix will be supporting / moving functionality only available in a dedicated desktop to a pooled desktop because a pooled desktop is ideal because of the simplified management.

Storage for a pooled desktop group occupies about 1GB of storage for each virtual desktop plus the base PVS vDisk image.  Your base PVS vDisk image will probably be about 10GB to 20GB depending on the OS and if you added any application streaming cab files to the base image.  Keep in mind you will want to store multiple versions of the base PVS vDisk image in case you need to revert back to a previous copy.  Some storage vendors offer features to efficiently store the copies of the base vDisk image.

Storage for an assigned desktop group occupies 10GB to 20GB for each virtual desktop.  With a large number of virtual desktops this takes a significant amount of storage.  However by leveraging features storage vendors offer you can dramatically reduce the storage required.  Keep in mind this will only reduce your storage requirements and will not provide the simplified management that a pooled desktop group offers.

Leveraging storage vendors features

Let's take a basic look at features that storage vendors offer that can be leveraged in XenDesktop.

1. Thin Provisioning -  Thin provisioning allows space to be easily allocated to servers, on a just-enough and just-in-time basis.  For example let's say you allocated 100GB to a user with only 20GB currently being used.  Normally the other 80GB could not be used, but with thin provisioning the 80GB could be used for other purposes.
2. Data Deduplication - This refers to the elimination of redundant data. In the deduplication process, duplicate data is deleted, leaving only one copy of the data to be stored.  For example if you have two different versions of a base 15GB vDisk image it would normally take 30GB to store.  However with data deduplication the redundant data is only stored once.  Each subsequent instance is just referenced back to the one saved copy so the 30GB is reduced to 15GB plus the difference between the two versions.
3. Rapid Cloning -  I am not sure what the industry term is for this but this involves creating writable clones of volumes or LUNs.  The clones can be quickly created with basically no storage overhead.  They share the same underlying storage blocks as their baseline volume/ LUN.  Currently vendors support this at the LUN or volume level but vendors like NetApp will soon support this at the file level.  With file level support you can quickly create copies of the base vDisk image and only consume additional storage for the actual changes between vDisk versions.

So that is my overview on storage with XenDesktop.  If you have any questions or have new ways to leverage storage features with XenDesktop check out the new XenDesktop CDN site or leave a comment.

XenDesktop offers a powerful way to update all virtual desktops just by updating your shared base image.  Most of this functionality is provided via the Provisioning Server component of XenDesktop.  Some storage vendors offer significant storage savings for saving multiple copies of the base Provisioning Server vDisk image.  For background information on XenDesktop please refer to the XenDesktop Getting Started Guide or related documentation.

Listed below are the steps required to update a Provisioning Server vDisk image for use with XenDesktop.  This common vDisk image is shared across all virtual desktops in a XenDesktop desktop group.  Each virtual desktop OS image is identical when the virtual desktop is started.  During boot the virtual desktop is customized for that virtual desktop VM by changing items such as the hostname.  When the user logs in their profile is applied and they are authenticated to the XenApp for virtual desktops component that gives them access to their authorized applications.  The "writes" for each virtual desktop are stored in a separate write back cache for each virtual desktop.  This write back cache can be stored on the same storage device where the base vDisk image is located or on a virtual hard disk for each virtual desktop VM.

Since each virtual desktop boots using the same clean PVS vDisk how would you handle any needed updates such as patches?  The answer is to create a new version of the PVS vDisk that you will update and then assign that new vDisk to all the virtual desktops in the desktop group.

To accomplish this perform the following steps in the Provisioning Server (PVS) console in XenDesktop.

1. Create a group for the client target devices in PVS and move target devices in the PVS group.  We created a group called "Sales".  The PVS target devices will have been created by the XenDesktop Setup Tool.  Note this step is mostly for convenience.
2. In the vDisk create a class name and a type name. In our case we used a classname of "SalesClass" and a type name of "SalesType".  These names can be whatever you want but must match the names used in later steps.
3. In one of the target devices in the PVS group set the class name as the name listed above. In our case the name is "SalesClass".  Note that the client target devices do not have a type name.
4. Copy and Paste the class name for all the other target devices in the PVS group.  Right-click on the target device and select Copy.  Be sure to only copy the class name as selecting and pasting other choices could cause problems.
5. Make copy of the vDisk and rename it.  Put this vDisk in the same vDisk repository already configured.  This should be done from Windows Explorer and not the PVS console.
6. Add the new vDisk in the PVS console by right clicking on the PVS host, selecting "New vdisk" and select "Existing" to add this new vDisk.
7. In the copied vDisk set the class and type to the values used above.  In our case it was "SalesClass" and "SalesType".
8. Increment the build number in the new vDisk.  The build number is how PVS knows which vDisk is newer.
9. Set the new vDisk to private image mode.  This is required to make changes to the vDisk.
10. Assign a desktop VM (target device) to the new vDisk.  Be sure the new desktop VM is set to boot from virtual disk.
11. Boot the desktop VM and make updates.  In this step you will make any updates you desire to the base image.
12. Shutdown the desktop VM and set to standard mode.  We need to set the mode back to standard so it can be shared across multiple virtual desktops.
13. In the PVS console enable "Check for new versions of a virtual disk" in the PVS host "Options" tab.  This will require the PVS streaming service to be restarted.  This step only needs to be done once as this is set for each PVS host.
14. In the old and new vDisk check "Enable automatic updates" in the Disk Mode tab.  This step only needs to be done once per vDisk.
15. To check for an update immediately, right click on PVS host and select "Check for disk updates" followed by "Check for updated virtual disks".
16. When the virtual desktop VMs boot they will be assigned the new vDisk.  When users log off their virtual desktop, the virtual desktop VM will be restarted and will pull down the new updated vDisk image.

These are all the steps to update your base image.  Some storage vendors offer functionality to improve upon storage utilization and also allow for faster cloning.  For example data deduplication can be used on the vDisk repository so that only the differences between different version of the base vDisk images are stored.  Some storage vendors such as NetApp will soon allow for file level cloning which will be more effective for quickly cloning a base vDisk image.  So when you create a file copy it would be nearly instantaneous and use almost no additional storage.  This differs from data deduplication because in this case each block in the base vDisk image would first need to be copied and you will need to take time and hard disk throughput to perform the data deduplication to get the storage savings.

For additional information please refer to the new XenDesktop CDN site.

The XenDesktop Setup Wizard allows an administrator to quickly create a pooled desktop group with virtual desktop VMs for their XenDesktop environment.  I wanted to share more information on what the XD Setup Wizard does along with promoting it as we have had several customers unaware of the benefits of this wizard.  If you are going to create a desktop group of pooled desktops then you should seriously consider using the XD Setup Wizard as it will save you a tremendous amount of time.  Trust me on this as I needed to create 300 virtual desktops on VMware ESX two years ago which led to me creating this wizard.  But I will save that talk for another time.

First let's cover the prerequisites and initial configuration...

Before the XenDesktop Setup Wizard is run you need to have a virtual desktop VM template and a base OS image (aka Provisioning Server vDisk).  For detailed setup information on how to accomplish this please refer to the XenDesktop Getting Started Guide.  This guide describes the configuration for the XD Setup Wizard as well as the other components of XenDesktop.  

When you create your virtual desktop VM template you specify the VM hardware parameters for your base virtual desktop VM.   When the XD Setup Wizard is run it reads this VM configuration information and then creates X number of VMs using the same virtual hardware configuration.  For example if you created a VM on XenServer that has 512MB of RAM, 1 virtual CPU, 1 virtual NIC and no virtual hard drive all your new virtual desktop VMs would have that same configuration.  Keep in mind that you do not need to have a nice round number in terms of RAM.  You could try using something like 460MB of RAM per desktop to try and squeeze one or two extra desktop VMs per server.  Of course that would only help if RAM was your bottleneck.  No virtual hard drive for the VM is possible because Provisioning Server (PVS) dynamically streams the base OS image to the VM which does not require a hard drive in the VM.

However, in advanced cases you may want add a virtual hard drive to the VM that will cache information from the streamed base OS image.  This virtual hard drive will be used as the write back cache for the Provisioning Server (PVS) base OS image and will typically be 1 to 2 GB.  Whether or not you want a virtual hard drive depends on your network configuration and storage.  By moving the write back cache off the network storage that also has the PVS base OS image you reduce the load on your network storage and you balance your network load.  However having your PVS base OS image and the write back cache for each desktop on the same storage device makes the configuration easier and can result in better storage utilization.  These are some of the trade offs to consider when you want to have virtual desktops deployments for thousands of users.  If you need to scale your virtual desktop environment to over a thousand users email me at sunil.kumar@citrix.com.

When you create your virtual desktops you will be asked for the base VM template, the base OS image (Provisioning Server virtual disk),  the base host name along with the number of virtual desktops to create, and the name of the desktop group.  In our case let's use

• "CXD_VM_TEMPLATE" as the base VM template
• "CXD_IMAGE" as the base OS image
• "CXD1, CXD2, ... CXD100" as the name of the virtual desktops.
• "CXD_GROUP" as the desktop group name.

You will be asked for all this information when you run the wizard to create a desktop group.  The attached video walks you through this configuration. 

Now let's look at what happens when the wizard starts creating virtual desktops ...

Step 1: Connect to the hosting infrastructure and create new virtual desktops 

The XD Setup Wizard connects to the XenServer resource pool via the master XenServer.  It instructs XenServer to create X number of VMs.  In our case we created 100 VMs.  A new MAC address is created for each VM that corresponds to the virtual NIC for the VM.  The XD Setup Wizard stores this newly created MAC address for each VM along with the host name specified (CXD1, CXD2, ... CXD100).  The XD Setup Wizard uses the first MAC address for the VM if multiple NICs are used.  However I would avoid this configuration because bad things could happen if you try it.  Well actually the worst that could happen is that your virtual desktop would not boot, but because of the complexities of having multiple NICs I would avoid this configuration unless you could not live without having multiple NICs.  We now have 100 VMs created with the XD Setup Wizard storing the host name for each VM along with the MAC address.

Step 2: Configure virtual desktops in Provisioning Server

The XD Setup Wizard adds a target device in Provisioning Server for each of the virtual desktops.  The client name for each of the target devices is the host name.  When the VM boots it replaces the host name of the base OS image with this client name.  Each target device is uniquely identified by the MAC address which is why we stored the MAC address for each VM in the previous step.  Each target device is then set to boot from the specified base OS image (CXD_IMAGE).  In addition Provisioning Server adds each target device to active directory.  You can either let the XD Setup Wizard add computers to the default location or you can specify a custom OU.  We now have 100 provisioning server target (client) devices that correspond to each of the VMs created in the previous step.

Step 3: Add virtual desktops to a new Desktop Group in a Desktop Farm

The wizard now creates the new desktop group we called "CXD_GROUP".  The 100 virtual desktop VMs created above are now added to this desktop group on the Desktop Delivery Controller (aka the Connection Broker or DDC).  The DDC identifies each of the VMs by their AD host name, but when the VMs are added the DDC can only see the VM name and UUID (Universal Identifier).  The wizard knows the host name for each VM so it informs the DDC of this automatically.  Otherwise the administrator would need to manually associate each VM name / UUID with its corresponding AD host name.  We now have a newly created desktop group with 100 virtual desktops.

Readying the desktop group for use

Once the desktop group is created, the Desktop Delivery Controller takes over and starts the initial setup for the desktop group.  This includes starting the idle virtual desktops.  These idle desktops are used to quickly connect a user to a virtual desktop because the virtual desktop is already running and only the profile needs to be applied when the user logs in.  The DDC informs the XenServer resource pool to start a virtual desktop VM.  When this virtual desktop is started it streams down the base OS image using the Provisioning Server component.  The virtual desktop loads the Virtual Desktop Agent as part of the OS boot process which then registers with the DDCs in the XenDesktop farm.  The desktop group is now ready!

In addition to the XenDesktop Setup Wizard automating all of this for you it only takes seconds per desktop.  Are you now convinced to use the XenDesktop Setup Wizard as opposed to doing everything manually?  You can now run the XD Setup Wizard again to either create a new desktop group or add new VMs to an existing desktop group.  To modify advanced options of the desktop group such as idle pool settings you can run the Access Management Console on the DDC.