View Composer, relocating replica

I’m helping out some past students with a storage issue at a View implementation.  They need a question answered about moving between datastores when Tiered storage is in use. 

Without Tiered storage it is fairly easy to add and remove datastores from a pool, as is described in the VMware Knowledgebase article on the subject or the other Knowledgebase article also about the subject.  The two articles imply that the same is true with tiered storage, however it isn’t true until it’s tested.  So here’s my testing.

If you’re unfamiliar with View Composer and tiered storage then head on over to Andre’s blog post on the subject.

I created a dedicated assignment, linked clone pool using Tiered storage.  The Master VM is a fairly bare Windows XP install with the View 5.0 agent installed.  Initially the Replica is on the datastore NFS2 and the OS disk on NFS1 as shown below.

I deployed the pool, just a single VM and logged onto the desktop, customising the desktop to reflect the current storage setup.  I created a new bitmap on C: drive, not in my user profile, listing the disks in use.

Next I edited the pool to change the replica datastore to NFS3, leaving the OS disk on NFS1.

Nothing happened to the VM or the replica, they remained in their original locations on NFS1 & NFS2.  To make my configuration changes apply to the existing desktop I had to rebalance the pool, this forced my desktop session to logoff.

Then a new replica was created on the NFS3 datastore and my desktop was attached to that replica.  The replica on NFS2 was deleted when no more desktops depended upon it.  Of course a rebalance implies a refresh, so my changes to my desktop (that weren’t in a roaming profile or persistent disk) were lost.  Since my desktop background was not in my roaming profile it was lost.

The next phase was to relocate the OS disk to a new datastore, I chose to move the OS disk to the datastore SATA1. The process was the same as for the Replica move, change the datastore settings and rebalance.  Again my desktop was shutdown and refreshed, this time the VM home directory was moved too.

A further test was to change both the replica and OS Disk datastores at the same time.  To avoid the outage to my VM for the creation of the replica I created a new desktop on the pool at the same time as changing datastore, this caused the new replica to be created before the  rebalance. 

Once the new replica was in place I rebalanced and my desktop was back in it’s original location.

My final test was to reconfigure the pool again and then rebalance a single desktop, rather than the whole pool.  I again changed both the replica and OS Disk datastores, this didn’t cause any change to the VMs.  I then rebalanced just one desktop, by selecting it in the Inventory list for the pool. This caused a new Replica to be created and the desktop moved to the new datastore.  My other desktop was unaffected until I chose to rebalance the whole pool.

What did we learn?

• Tiered storage does not prevent datastores being changed.
• Newly deployed Desktops get the currently configured values.
• Rebalance is required for changes to datastore selection to be applied to existing Desktops.
• Changing any of the datastores used for a desktop cause a refresh, loosing all OS disk changes made by the user that aren’t being captured by roaming profiles, Persona Management or a persistent disk.
• It is possible to rebalance a pool progressively by rebalancing individual desktops, or groups of desktops.

© 2012, Alastair. All rights reserved.