There are several types of disks—OS disk, secondary OS disk, user data disk, and temp data disk.
The OS disk stores the system data (for example, Windows 7) and provides the base for a functional desktop.
The secondary OS disk stores OS data that must be preserved during certain View Composer activities (such as Refresh or Recompose). Each virtual desktop will have a secondary OS disk. These disks are typically 10 MB in size and are not configurable.
The secondary OS disk can only be stored on the same data store as the OS disk.
A persistent user data disk is an optional component of a View virtual desktop. The user data disk stores the user profile information. By storing this information on a persistent disk, View Composer actions such as Refresh and Recompose will not affect the user profile data. The alternative is to store this information inside the OS disk, which would cause user profile data to be lost during a Refresh or Recompose task.
The size of the user data disk is configurable. In addition, the persistent user data disk can be stored on the same data store as the OS disk or on a separate data store.
A non-persistent temp data disk is an optional component of a View virtual desktop. It is also referred to as the disposable disk. The temp data disk stores the OS swap file as well as temporary data that is created during a user session. By storing this information on a non-persistent disk, View will delete all data stored on the disk whenever the virtual desktop is powered off. This can help minimize the growth (in MB) of the virtual desktop as disposable user interaction is discarded and does not become part of the standard OS disk for each respective user.
The size of the temp data disk is configurable. The temp data disk can only be stored on the same data store as the OS disk.
The following is a list of the available options of the disk types and the redirection:
The following figure illustrates the preceding disk types and their redirection. Note that the secondary OS disk is not illustrated as it is not a configurable option within View.
When a virtual disk is created using
thin provisioning, the disk only occupies the actual data size on the disk. For example, a virtual disk (.vmdk) that is 20 GB in size but has only 8 GB of data will occupy only 8 GB on the data store. Two virtual desktops that have a 20 GB virtual disk but only 8 GB of data per disk will occupy 16 GB on the data store.
When a VM that is using thin provisioning needs to write new data to the virtual disk (and thereby increase the size of the virtual disk), it does so in the blocks defined by the data store's block size. The data store's block size is defined prior to being formatted in the Virtual Machine File System (VMFS) format. In VMware vSphere 5, the newly created data stores (versus the ones upgraded from vSphere) use a unified block size of 1 MB.
For example, if the VM is located on a 500 GB VMFS-3 block, which is the data store that was formatted using a 2 MB block size, a 10 MB new write operation will require the write of 5 blocks (10 MB file/2 MB block size), which results in a less efficient usage of the overall storage space.
Note
Thin provisioning makes it possible to over-allocate the available storage and can introduce significant issues if not monitored and managed properly.
When a virtual disk is created using thick provisioning (default), the disk occupies its entire allocated size on the disk. For example, a virtual disk that is 20 GB in size but has only 8 GB of data will occupy 20 GB on the data store. Two virtual desktops that have a 20 GB virtual disk but only 8 GB of data per disk will occupy 40 GB on the data store.
When using linked clones, there are several actions that can be performed on the clones themselves. These actions are discussed in the following sections.
The Reset action is equivalent to hitting the Reset button on a virtual machine. This is an ungraceful restart of a virtual machine that is equivalent to pulling the power cable out of a desktop and then plugging it back in.
The Refresh action is an action that resets the delta disk back to its original state. An OS delta disk bloat can happen as a user continues to write changes to their delta disk over time. Data inside the OS delta disk is lost during a Refresh action.
The Recompose action is an action that is used to change the snapshot and/or a parent VM that is used by the desktop pool. In the following figure, number 1 is the original mapping to a base snapshot, and number 2 represents the available options during a Recompose action.
Administrators can use the Recompose action in the following scenarios:
To change the linked clone pool to use a different snapshot (for example, Snapshot_B) of the original parent (for example, ParentVM_1) instead of the current one in use
To change the linked clone pool to use a snapshot (for example, Snapshot_A) of a different parent (for example, ParentVM_2) instead of the current parent in use
The Rebalance action is an action that will evenly distribute desktops across all of the available data stores in the desktop pool. The desktop must be in the ready, error, or customizing state (with no pending tasks or cancellations) to be rebalanced.
A Rebalance action automatically executes the Refresh action on the desktop as well, which resets the OS disk back to its original state.
During a Rebalance action, the administrator can set whether to rebalance the desktop once the users log off of their desktop or to force all of the active users to log off.
The Rebalance action is also the only supported way to move linked clones to a new data store.