Throughout my time spent with VMware View, I’ve been asked a wide range of questions that begin with “What happens when I …” that involved some tinkering. While results vary, my overall impression is that View is pretty dang hard to break, even when you push the limits of what I feel its designed to do “properly”. Here are a few behaviors I found to be interesting enough to share.

There’s a lot of View lingo in this post. If you’d like a quick 101 on how View works, I recommend this post I wrote up on the subject or you can watch this video on disk redirection.

Modifying Snapshots on a Linked Clone Desktop VM

When View creates a linked clone, the first action is to take a snapshot of the VM before making it available for use. When a Refresh task is started, the VM reverts back to its originally provisioned state. Behind the scenes, View Manager is actually just discarding the changes made since the initial checkpoint snapshot. Here are the answers to two different snapshot questions.

What happens if you destroy or commit the checkpoint snapshot of a linked clone?

The answer is pretty simple. View Manager apparently recognizes that the checkpoint snapshot no longer exists and instead performs a Recompose task. Realistically, a Refresh and Recompose are identical in results when the replica does not change. However, reverting to a snapshot is a much less intense workload when compared to detaching an internal and user disk (persistent disk), destroying a VM, creating a new one, and then re-attaching the disks.

Since View 4.5, Refresh tasks simply revert to this checkpoint snapshot

What happens when additional snapshots are added to a linked clone?

Performance aside, View Manager doesn’t seem to care about additional snapshots that have been added to a linked clone. Refresh tasks still roll back to the checkpoint snapshot and start a new “branch” of snapshots. There is a danger of amassing too many snapshots, as the previously created branch will still exist, soaking up disk capacity. A Recompose task does wipe the slate clean, removing any snapshots.

Additionally, if you make a change to the portgroup that a VM belongs to and take an additional snapshot, the VM will show up in both portgroups. This typically throws up eyebrows the first time you see it.

Modifying the vSphere Name of a Desktop VM

By changing the name, I don’t mean the NetBIOS name of the VM, but rather the vSphere name of the object. View Manager doesn’t care if you change the name, but it also doesn’t update the name within the View Administrator either. The only place you’ll see the new name reflect is in details of the desktop within the View Administrator (the vCenter Settings of the object). View Manager doesn’t use the name to reference a VM object – that’s actually quite smart as the name field is not a unique field outside of a folder: you can use the same VM name as much as you’d like as long as the objects do not co-exist in a folder together.

This is the only place you’ll see the updated name in View Administrator (LabDesktop-01 renamed to LabDesktop-01OMG)

Refresh and Recompose tasks work just fine on desktops that have been renamed. Just remember – the name doesn’t update in the Desktops section of the Inventory, so you may have to go hunting for the desktop VM you’re looking for if you radically change the name.

Modifying the Folder Path Structure

Changing any piece of the path to the desktop breaks View provisioning but doesn’t seem to impact Refresh and Recompose tasks. The name absolutely has to match or provisioning actions will fail citing that it could not find the container it was looking for. If you want to make any changes to the folder paths, you’ll need to use the ADSI trick I outline in this post or simply recreate the pool from scratch. The VM folder object is read only within the View Administrator.

VM folder is read only within View Administrator

Thoughts

The VMware View product is robust enough to handle most of the common curve balls you can throw at it. If you found some other “fun facts” with View, leave a comment for all to see. 🙂