posted

0 Comments

In Part I, we covered the basics of what a linked clone is, the basic structure, and how a linked clone is provisioned. In this follow-up piece, we’ll look at the 3 major operations performed on a linked clone. Refresh, recompose, and re-balance.

Refresh

As mentioned in Part I, a checkpoint is created containing the individual customizations to the VM that differentiates it from the replica. This checkpoint contains things like the machine password, domain information, Windows name, etc. This checkpoint is a snapshot of the VM post customization. The refresh operation reverts the VM to this checkpoint snapshot.

View Connection Server changes the status of the VM to Maintenance to tag it as unusable, reverts to the previous checkpoint snapshot, and after start-up, the View Composer agent updates the machine account password if needed. View Connection Server then sets the machine back to Provisioned, or Available to meet the pool requirements.

The Desktop is now ready for use.

Recompose

A recompose lets you redeploy an existing View desktop while preserving any persistent or user data disks that may be attached to the VM.

When a recompose is performed with no configuration change (no new snapshot), no recompose will occur because Composer will detect that no changes will be made. The difference between using an existing template/snapshot and a new template/snapshot is a new replica is needed with a new snapshot. The new replica is cloned from the snapshot, and a new checkpoint and difference disk are created.

View changes the status of the desktop to Maintenance and creates the new snapshot if needed. Though the VM hardware is not replaced, this is a new VM and is customized using the same process as a newly provisioned desktop with a new checkpoint and difference disk. View then sets the machine back to Provisioned, or Available to meet the pool requirements.

The difference between using an existing template/snapshot and a new template/snapshot is a new replica is needed with a new snapshot. The new replica is cloned from the snapshot, and a new checkpoint and difference disk are created.

View Connection Server changes the status of the desktop to Maintenance and creates the new snapshot if needed. Though the VM hardware is not replaced, this is a new VM and is customized using the same process as a newly provisioned desktop with a new checkpoint and difference disk. View then sets the machine back to Provisioned, or Available to meet the pool requirements.

Re-balance

A re-balance serves 2 purposes-

  1. It will redistribute linked clones to use available free storage space.
  2. It is the only supported method to migrate linked clones between datastores. Storage vMotion will break a linked clone.

A re-balance will try to ensure all configured datastores are equally used based on the amount of available free space. I will not be discussing the algorithm used here because it is dependent on the version of View and the storage over commit settings. View will investigate each datastore the pool is configured to use, and determine which linked clones to migrate. It is possible during a re-balance that no desktops will be migrated. A refresh operation will also occur on all affected desktops.

When a re-balance occurs, the VM status is changed to Maintenance. View will then detach any persistent disks and move them and the VM to the new datastore. The persistent disks are attached to the VM at the new location. If a replica for the pool does not exist at the new location, Composer will request a new replica to be cloned by vCenter to be placed on that datastore. Composer will then attach the linked clone to the replica and customization occurs with a new checkpoint and difference disk. View will then set the machine back to Provisioned, or Available to meet the pool requirements.

A re-balance can also be used to vacate a datastore. Deselecting a datastore from a linked clone pool settings and then performing a re-balance on the pool will cause all associated linked clones from the pool to be migrating to another datastore (when possible). This is often used to migrate a linked clone pool from one datastore to another.
This covers the basics of what a linked clone is, and what maintenance and administrative options are available.