7.0

If you intend to take advantage of the benefits of local storage, you must carefully consider the
consequences of not having VMotion, HA, DRS, and other features available. If you manage local disk usage
by controlling the number and disk growth of the virtual machines, if you use floating assignments and
perform regular refresh and delete operations, you can successfully deploy linked clones to local datastores.
Storing Replicas and Clones on Separate Datastores for Instant
Clones and View Composer Linked Clones
You can place replicas and clones on separate datastores with different performance characteristics. This
configuration can speed up disk-intensive operations such as provisioning or running antivirus scans,
especially for View Composer linked clones.
For example, you can store the replica VMs on a solid-state disk-backed datastore. Solid-state disks have
low storage capacity and high read performance, typically supporting 20,000 I/Os per second (IOPS). A
typical environment has only a small number of replica VMs, so replicas do not require much storage.
You can store clones on traditional, spinning media-backed datastores. These disks provide lower
performance, typically supporting 200 IOPS. They are cheap and provide high storage capacity, which
makes them suited for storing the a large number of clones.
Configuring replicas and clones in this way can reduce the impact of I/O storms that occur when many
clones are created at once, especially for View Composer linked clones. For example, if you deploy a
floating-assignment pool with a delete-machine-on-logoff policy, and your users start work at the same
time, View must concurrently provision new machines for them.
IMPORTANT This feature is designed for specific storage configurations provided by vendors who offer high-
performance disk solutions. Do not store replicas on a separate datastore if your storage hardware does not
support high-read performance.
You must follow certain requirements when you store the replica and clones in a pool on separate
datastores:
n
You can specify only one separate replica datastore for a pool.
n
The replica datastore must be accessible from all ESXi hosts in the cluster.
n
For View Composer linked clones, if the clones are on local datastores, VMware strongly recommends
that you store the replica on the same volume as the linked clones. Although it is possible to store
linked clones on local datastores and the replica on a shared datastore if all ESXi hosts in the cluster can
access the replica, VMware does not recommend this configuration.
n
This feature is not available you use Virtual SAN datastores or Virtual Volumes datastores. These types
of datastores use Software Policy-Based Management, so that storage profiles define which components
go on which types of disks.
Availability Considerations for Storing Replicas on a Separate Datastore
You can store replica VMs on a separate datastore or on the same datastores as the clones. These
configurations affect the availability of the pool in different ways.
When you store replicas on the same datastores as the clones, to enhance availability, a separate replica is
created on each datastore. If a datastore becomes unavailable, only the clones on that datastore are affected.
Clones on other datastores continue to run.
When you store replicas on a separate datastore, all clones in the pool are anchored to the replicas on that
datastore. If the datastore becomes unavailable, the entire pool is unavailable.
To enhance the availability of the desktop pool, you can configure a high-availability solution for the
datastore on which you store the replicas.
Chapter 16 Reducing and Managing Storage Requirements
VMware, Inc. 249