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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.