In addition to offering a conceptual overview of how linked clone desktops are created within VirtualCenter by View Composer and managed by View Manager, the following sections describe
Trang 1Virtual Printing consists of a guest component (.print Client) which resides within the View Client or View Client with Offline Desktop application, and a host component (.print Engine) which is part of the View Agent service on the View Manager desktop. Jobs are sent by .print Engine to .print Client over an RDP connection
Where a user has administrative privileges, printer drivers can still be installed on the View Manager desktop; this action does not interfere with the virtual printing component
To configure a virtual printer instance on the View Manager desktop
1 Click Start > Settings > Printers and Faxes. The Printers and Faxes window is
displayed
2 Right‐click any of the locally available printers and select Properties from the
context menu. You are presented with the print properties window associated with the selected printer
3 Select the ThinPrint Device Setup tab.
4 Using the slider, select an option for print data compression:
No images—Only text is printed.
Extreme—Images are compressed with maximum possible compression rate
without regard to image quality
Maximum—Images are compressed with good quality.
Optimal—Images are compressed with optimal quality.
Enable or disable the duplex and Show tray selection check boxes as required.
5 Select the General tab and click Printing Preferences.
6 Edit the page and color settings; the default values are acquired from the host printer
N OTE On an offline desktop, .print Engine uses a named pipe (Com1:) to pass print
data to .print Client
Trang 27 Click the Advanced tab. If the printer installed on the host supports these options,
edit the following settings for double‐sided printing: Long edge for portrait or Short edge for landscape printing
To preview each printout on the host, enable Preview on client before printing.
From this preview, you can use any printer with all its available properties
8 Click the Adjustment tab to view the automatic print adjustment options. VMware
recommends that you retain the default settings
9 Click Apply or OK. Click OK to close the print properties window.
Trang 3alternative to creating and managing many standalone virtual machines. This chapter provides an overview of View Composer functionality of View Manager.
In addition to offering a conceptual overview of how linked clone desktops are created within VirtualCenter by View Composer and managed by View Manager, the following sections describe how to prepare VirtualCenter and a base virtual machine image for use in a View Composer deployment
This chapter discusses the following topics:
“Overview of View Composer” on page 93
“Preparing VirtualCenter for View Composer” on page 102
“Preparing a Parent VM” on page 106
“Deploying Linked Clone Desktops from View Manager” on page 108
“Refreshing, Recomposing, and Rebalancing Linked Clone Desktops” on page 116
“Using an Existing Linked Clone Desktop Database” on page 120
Overview of View Composer
The View Composer feature enables View Manager administrators to rapidly clone and deploy multiple desktops from a single centralized base image, called a Parent VM. Once the desktops have been created they remain indirectly linked to a snapshot residing on the Parent VM
Trang 4The link is indirect because the first time one or more desktop clones are created, a uniquely identified copy of the Parent VM—called a replica—is also created. All the desktop clones are anchored directly to the replica and not to the Parent VM. Desktops
of this type are called linked clone desktops
The Parent VM can be updated or replaced without directly affecting the linked clone desktops and can therefore can be viewed as a standalone virtual machine. This set of relationships is illustrated in Figure 6‐1
Figure 6-1 Parent VM, Linked Replica, and Desktop Clones
Because all the linked clone desktops in this environment are connected to a common source, View Composer permits the centralized management of desktops while maintaining a seamless user experience. Tasks such as resetting each system to its default configuration, balancing storage, installing software, and applying service packs are greatly accelerated by this type of deployment
View Manager administrators can simultaneously update (or change) the operating systems of all linked clone desktops, install or update client applications, or modify the desktop hardware settings by carrying out these activities on the Parent VM and then anchoring the linked clones to a new snapshot of this configuration. This action is called desktop recomposition
N OTE If a replica is deleted the desktops anchored to them will cease to work, so
replicas are treated as protected entities within VirtualCenter
base image + snapshot
user data disk
replica
OS data disk OS data disk user data disk
parent VM can be
on a different datastore
Trang 5Administrators can also return the operating system data of each linked clone desktop—which may have expanded through ongoing usage—to its original state (that of the Parent VM) by carrying out an action called desktop refresh
View Administrator delivers a high‐level overview of what actions are being carried out. Policies can control what actions are executed and at what time in order to minimize disruption to the user base. Connected users can be notified with custom messages if an update that will affect their session is about to take place
Linked Clone Desktop Disk Usage
The initial disk usage of a linked clone virtual machine is far lower than that of a full clone because the operating system and client applications are derived from a Parent
VM. The greatly reduced storage overhead for operating system and user data is accomplished through the use of delta disks and thin provisioning
Every new desktop created in a standard (non‐linked clone) automated pool is a duplicate of a base template. Consequently, each standard clone uses the same amount
of disk space as the base template because the operating system data and user data of the base template is replicated by every clone created in the pool
View Composer greatly reduces the physical storage overhead of linked clone desktop pools through use of delta disks: abstract storage mechanisms whose logical size can be greater than their physical size. Thin disk growth depends on factors such as workload, power‐off policy, pool type and so forth
In a linked clone deployment, delta disks are used by the desktop to store the data difference between its own operating system and the operating system of the Parent
VM from which it is derived. Immediately after deployment, the difference between the Parent VM and each of its linked clones is extremely small; thus, the delta disk is also extremely small.
Because the delta disks for each desktop will inevitably grow over time, during linked clone deployment you can define the maximum allowable size of each virtual machine,
up to the original size of the Parent VM. The amount of disk space required to store the difference between the linked clone operating system data and Parent VM operating system data will typically remain far smaller than that required by a standard clone. If the size of the delta disk gets too large it can be returned to its baseline state by carrying out a desktop refresh
N OTE Linked clones can also be anchored to a new snapshot of a completely different
Parent VM.
Trang 6Thin provisioned disks (thin disks) are used by the linked clones to store user data, and are not linked to the Parent VM. This type of disk occupies no more space than that required by the data it contains but does not reduce in size if data is removed. These disks are not affected by recomposition or refresh events
Storage Overcommit
When the datastore for a new linked clone desktop pool is being assigned,
administrators can control how aggressively the system assigns new virtual machines
to the free space available on the datastore by modifying the storage overcommit property
When the storage overcommit level is low, the majority of free space is used as buffer
in which the delta disks for each clone can expand. As the overcommit level increases, less space is reserved for individual delta disk growth but more virtual machines will fit on the datastore
A very aggressive level of storage overcommit results in a relatively small amount of space being reserved for delta disk expansion; however, administrators can add a lot of extra virtual machines to the datastore if they predict that the delta disks of each virtual machine will never grow to their maximum possible size.
While a high overcommit level may be optimal for creating a large number of virtual machines, a desktop pool of this type also demands more attention from the
administrator in order to ensure that the remaining disk space is not completely consumed by virtual machine expansion. This condition can be prevented by
periodically refreshing or rebalancing the desktop pool and reducing the size of the operating system data to its baseline level
Storage overcommit levels can be varied between different types of datatstores in order
to address the different levels of throughput on each datastore (for example, NAS versus SAN). Where throughput is relatively slow, the overcommit level can be set to a lower level to ensure that a smaller number of clones are created on the datastore. Conversely, a higher level of overcommit could be applied to datastores that exhibit a greater rate of data transfer
Storage overcommit only applies to delta disks. It does not apply to user disks or standard (non linked) clones where thin disks are used
Desktop Recomposition
In Figure 6‐2 an assigned desktop clone is linked to replica 1, which itself is a copy of Parent VM 1. A recomposition action is initiated when the administrator selects a different snapshot in the same Parent VM or different Parent VM (as in this example).
In either case a new replica is provisioned
Trang 7Figure 6-2 Desktop Recomposition
Replica 2 is an exact copy of Parent VM 2. When the recomposition action is complete the desktop will be anchored to replica 2 and the operating system data modified accordingly. The operating system data of a recomposed desktop is reduced in size after recomposition, however the user data is unaffected by this event
Source Virtual Machine
Recomposition is expedited through the use of an additional protected linked clone desktop in VirtualCenter— called a source virtual machine—that is created alongside the replica when a linked clone desktop pool is first deployed
When a recomposition event takes place, the source virtual machine is the first desktop
to be recomposed against a new snapshot. View Composer removes the existing linked clone desktop pool from VirtualCenter and then copies the source virtual machine as many times as necessary in order to replace it.
This method of pool generation optimizes the recomposition process and is typically much faster than individually recomposing each linked clone desktop in the pool
N OTE The source virtual machine is located with the replica inside a folder called
VMwareViewComposerReplicaFolder in VirtualCenter
base image + snapshot
bloated
OS data disk
refreshed
OS data disk
replica 2—
new base image after recomposition replica 1
parent VM 1
base image + snapshot parent VM 2
recompose
Trang 8Desktop Refresh
A desktop refresh is similar to a desktop recomposition but without any change to the base image. This action is carried out in order to restore the system data for a desktop pool to a baseline state and thereby reduce the size of the operating system data of each attached clone.
A desktop refresh can be carried out either on demand, as a timed event, or when the operating system data reaches a specified size. Figure 6‐3 illustrates the effect of this action—note that the user data disk remains unaffected by this event
Figure 6-3 Desktops Refresh
It is important to occasionally refresh the attached systems in order to prevent the desktop clones growing to the size of a full virtual machine. If all the anchored virtual machines are left to grow unchecked then all free space remaining on the datastore could be rapidly consumed—particularly if the storage overcommit level is particularly aggressive
Desktop Rebalance
A logical drive is a structure created on a subsystem for data storage that is defined over
a set of drives called an array. Logical drives—often referred to as LUNs, which stands for Logical Unit Number and represents the identifier a host uses to access the logical drive—are the logical segmentation of arrays.
base image + snapshot
replica 1
parent VM
refresh
user data disk bloated
OS data disk
refreshed
OS data disk user data disk
Trang 9If administrators are creating large pools of desktops and are using multiple LUNs, there is a possibility that the space is not being used efficiently if the initial sizing was inaccurate. Figure 6‐4 shows a number of virtual desktops, distributed unevenly over two LUNs
Figure 6-4 Desktop Rebalance – Before
base image + snapshot
OS data disk
user data disk
replica 1
parent VM
LUN A
OS data disk user data disk
OS data disk user data disk
OS data disk user data disk
replica 2
LUN B free space
Trang 10Rebalancing the LUNs evenly distributes any selected (or all) virtual machines between the available logical drives. This result of this action is illustrated in Figure 6‐5
Figure 6-5 Desktop Rebalance – After
base image + snapshot
user data disk
OS data disk
replica 1
parent VM
LUN A
user data disk OS data disk
user data disk
replica 2
LUN B
Trang 11A high level of storage overcommit introduces the possibility of virtual machines growing to such a level that all free space within the datastore is consumed. When the volume of space being used by the virtual machines on the datastore reaches:
95%—A log entry is generated that states the datastore is short on free space
99%—Every virtual machine resident within the datastore is suspended
The rebalance feature offers administrators a graceful mechanism for introducing additional storage to a datastore in order to prevent the latter outcome. In addition, prior to executing the rebalance action you may also retire old storage and make resource pool alterations, and host changes
Only desktops in the Ready, Error, or Customizing state with no schedules or pending cancellations can be rebalanced. In addition, you cannot rebalance the load between the local storage systems on multiple standalone ESX servers
It is recommended to keep linked clone desktop virtual machines on a datastore with
no other type of virtual machine so that the rebalance action is applied to all the virtual machines
Persistent and Non-Persistent Desktops
Both persistent and non‐persistent desktop configurations are supported by View Composer. In persistent configurations, dedicated disks—a system disk for operating system data and a user disk for user data—can be used to keep the operating system and user data separate. This ensures that even if the operating system is recomposed or refreshed the user data remains unaffected
In non‐persistent configurations the user data is transient so both the operating system data and the user data is stored on the system disk. In this configuration user data is not protected if the system is recomposed or refreshed
N OTE In order to rebalance the desktops it is necessary for View Manager to
automatically refresh their operating systems against their current base image and return the system data to its baseline state—user data is unaffected if it resides on a separate user data disk.
N OTE Persistent desktops can be set to refresh automatically when the user logs off.
This can help minimize the space requirements of the pool. Similarly, non‐persistent pools can be set to delete after first use, which reduces the number of inactive desktops
in the pool overall