Linked-clone lifecycle in VMware View 4.5 and later

November 16th, 2011 by jason Leave a reply »

Remote connectivity to the lab is key when I’m on the go – a situation I find myself in more frequently.  In years past, the remote solution was hardware/software VPN endpoints, and then Citrix Presentation Server. Given my involvement with VMware, for the past year plus I’ve been a full fledged, trial by fire, eat my own evangelist food, View hobbyist.  What’s not to like about it?  It’s VMware based.  It’s secure.  It supports multiple connectivity protocols.  And it works absolutely great with my iPad (well, I’m talking about the remote desktop connectivity via PCoIP, not so much the Adobe Flex admin console for the View Connection Server).

One HUGE feature that View has touted since version 3.0 is Linked Clones which carry with it the positive attributes of space efficiency and fast provisioning.  Linked Clones are where some of the more advanced features and capabilities start to appear, such as View Composer.

VMware KB Article 1021506 has some great information in it surrounding linked clones, View Composer, Active Directory machine account passwords, and some of the common operational processes tied to it such as guest provisioning and customization, Refresh, Recompose, and Rebalance.  I find it to be a great reference.

A few excerpts on the operational pieces along with my notes:

Active Directory machine account passwords

While a linked clone is powered on and the View Composer Agent is running, the View Composer Agent tracks any changes made to the machine account password. In many Active Directory environments, the machine account password is changed periodically. If the View Composer Agent detects a password change, it updates the machine account password on the internal disk that was created with the linked clone. During a refresh operation, when the linked clone is reverted to the snapshot taken after customization, the agent can reset the machine account password to the latest one.

Refresh

In View 4.5, a refresh triggers a revert operation to the snapshot that was taken after customization was completed. This approach allows View to preserve the customization performed by Sysprep.

jgb: A Refresh should be run on a regular basis to reclaim valuable shared storage space.  As linked clone guests in the pool continue to run on an ongoing basis, storage consumption grows for each VM, much like a snapshot of a VM which is left open for a long period of time.  However, in this case, much of the data is transient and disposable which is what a Refresh will purge.  This data is stored on what’s called the Disposable Disk. The Disposable Disk contains data such as the Windows pagefile, Windows temporary files, Temporary Internet Files, and VMware log files.  It is not uncommon to run this Refresh on a nightly basis.  This is of particular importance on arrays which support auto tiering and especially sub LUN tiering at the block or page level because this meta data will most likely be consuming Tier 1 storage.

Recompose

A recompose operation lets the administrator preserve the View Composer persistent disk and all user data inside this disk while changing the OS disk to a new base image and snapshot. With recompose, an administrator can easily distribute OS patches and new software to users.

jgb: Net result is the deployed VMs in the pool are deleted and redeployed to the pool for the assigned users.

Rebalance

The rebalance operation redistributes linked clones among available datastores to take advantage of free storage space. In View 4.5, there is no other supported way to move linked clones from one datastore to another.

Advertisement

Comments are closed.