VMware View virtual desktops are merely virtual machines that are running a desktop operating system (e.g. Windows XP, Windows 7). The VMware View Agent is installed inside the virtual machine which allows connectivity from an end device running client software through the VMware View Connection Server.
As with regular virtual machines, virtual desktops live on datastores and, as with regular virtual machines, there may be times when a VMware View administrator needs to migrate existing virtual desktops off of one datastore and to another. Examples of these times include storage array migrations, storage array firmware or hardware upgrades, troubleshooting datastore performance, permanent relocation, data center migration, storage performance load balancing and so on.
Recently, a customer wanted to move a pool of virtual desktops to test out a new loaner storage array (to help them make a decision on a storage vendor switch).
To understand the rest of this article, we'll need to review some VMware View terminology:
- Desktop Pools: A collection of virtual desktops defined by a policy that includes attributes such as power state, protocol, deployment type, et cetera. There are two deployment types within each desktop pool: Full desktops and linked clone desktops (aka View Composer Desktops).
- Full Desktops: Traditional virtual machines that each have their own respective virtual disk(s). The virtual disk(s) can reside on one or multiple datastores. Tasks such as patching the underlying Windows OS need to be done on each virtual desktop individually.
- Linked Clone Desktops (or View Composer Desktops): Linked clone desktops within a desktop pool are desktops that are all linked back to a single parent virtual machine at a specific point in time (snapshot). Tasks such as patching the underlying Windows OS need to be done only once (on the parent VM).
Migrating linked clone VMware View desktops
Per VMware's What's New in VMware vSphere 4.0 article, which announced the graphical user interface (GUI) support for Storage vMotion, it clearly states that, "…snapshot mode is not supported in this release. Snapshots must be committed prior to executing the Storage vMotion session."
Committing a snapshot means making the changes permanent and effectively getting rid of your "save" points. If you don't want to make the changes permanent. Therefore, migrating a Linked Clone virtual desktop to a different datastore as-is is not supported. If you attempt to do this action you will be greeted with, "the virtual machine has a virtual disk in link-cloned mode that prevents migration."
If you try and get sneaky by editing a desktop pool using linked clones, removing the existing datastore(s), replacing it with the new datastore(s), and then adding desktops to the pool, the new desktops will still use the old datastores.
Linked clones (which use snapshot files) are tied to the unique ID of the datastore upon which they reside. It is important to note that Storage vMotions of multiple virtual desktops is a task that is likely best done after hours when disk and user activity is low.
Migrating full VMware View virtual desktops
For this example, let's say the original datastore is named datastore-old and the new datastore is named datastore-new.
The first step is to ensure that the desktop pool does not have any outstanding provisioning tasks. It is also a good idea to perform this migration after hours when you can suspend provisioning on the desktop pool altogether.
In the settings of the Desktop Pool, add datastore-new as an available datastore upon which to provision virtual desktops.
Manually, en masse or via a script, migrate the virtual desktops in the pool from datastore-old to datastore-new. This migration can be done online with Storage vMotion.
Proper VMware View architecture will likely have all of the virtual desktops in a pool residing in a resource pool. Simply highlight the resource pool and select all of the virtual desktops in the Virtual Machine tab in vCenter. Right click, select Migrate, then select Change datastore.
Once the virtual desktops have been successfully migrated, go back to the desktop pool and remove datastore-old. Moving forward, all provisioning tasks will build virtual desktops on the new datastore(s).
The final step is to re-enable provisioning on the desktop pool.
Storage DRS and Storage vMotion: A glimpse into the future
Storage Distributed Resource Scheduling (DRS), known as Storage DRS has been discussed for years . This takes the load balancing concepts of regular DRS and applies them to the datastore level. The concept will be covered at VMworld 2010 in Tech Preview: Storage DRS (TA7805).
What does this mean?
We have 100 virtual desktops spread across three datastores, Datastore-A, Datastore-B, and Datastore-C, respectively. Datastore-A is currently under moderate load. For whatever reason, Datastore-B is under heavy load while Datastore-C is doing nothing. The concept is that Storage DRS could migrate our virtual desktops (which, again remember are simply virtual machines) from Datastore-B to Datastore-C using Storage vMotion.
The real question becomes: When will Storage vMotion support snapshots?
ABOUT THE AUTHOR: Jason Langone heads virtualization, cloud computing and storage for
MicroTech, a service-disabled, veteran-owned and 8(a) small business. Langone won the VMware
Vanguard Award in 2007 and has architected some of the largest virtualization and cloud computing
implementations to date.
This was first published in August 2010