Why you should be using Dedicated Replica Datastores in View 4.5

This is one of those cases when, in my opinion, VMware was quite modest highlighting one of the VMware View 4.5 new features. VMware introduced with VMware View 4.5 the ability to select a different datastore to host Linked Clone replica disks.

If you are still unsure how Linked Clones and replicas work, please read these articles I have previously published.

Sizing Storage for VMware View Linked Clones
Real Life example of Storage Sizing for View Linked Clones
VMware View 4.5 Storage Tiering explained

I have only found this feature to be mildly explained in the View 4.5 Storage Considerations Guide; however Dedicated View Composer Replica Datastores is a huge storage space saver. When creating a new Desktop Pool in VMware View 4.5 there is an option to ‘Use different datastore for View Composer replica disk’. This option allows the administrator to assign different datastore that could be eventually hosted in a faster LUN or array of disks.


When replica disks are hosted in dedicated a datastore, virtual desktops in the vCenter Cluster (normally 8 host servers) will use that single View Composer replica disk as their base image for all virtual desktops in a cluster. This is true even if the Linked Clone disks are being housed in a different datastore, or if they belong to different desktop pools.

The View 4.5 Storage Considerations Guide says: “They are also expensive. However, View Composer creates only one replica for each View Composer base-image snapshot on each ESX cluster, so replicas do not require much storage space. A solid-state disk can improve the speed at which ESX reads a replica’s OS disk when a task is performed concurrently on many linked clones.”

Before View 4.5 replica disks would be created in each individual datastore hosting Linked Clones. In this case, if two or more snapshots were in use at the same time VMware View 4.0 and earlier would create two or more replicas per datastore.

Of course there is a caveat when using a single datastore to provide replica disk read access to all virtual desktops in the cluster. That datastore, the LUN, and the underlying disk array will suffer a large number of read requests. Those read requests need to be converted in IOPS (IO per Seconds) that if not delivered in the appropriate time (ms) could create performance bottlenecks on the infrastructure and affect all virtual desktops trying reading from the replica datastore. Finally, affecting end user experience.

Luckily most Microsoft OS frequently writes more than read. Windows 7 as an example executes 7 write IO for each 3 read IO out of 10 IOPS (70% write / 30% read). Using this example scenario 1,000 virtual desktops would require 3,000 IOPS to be pulled from the replica datastore. If you want read a little bit more on IOPS I recommend Improve VDI performance with IO Length Trending.

Let’s get back to the storage savings and provide a real example.

Scenario 1:

1,000 virtual desktops
30 GB Full Size of Image
08 GB Thin Size of Image
02 Concurrent Snapshots in Use
02 Desktop Pools
16 Datastores
8 hosts
1 cluster

Not using Dedicated Replica Datastore: 500 Megabytes
Using Dedicated Replica Datastore: 250 Megabytes

Scenario 2:

10,000 virtual desktops
30 GB Full Size of Image
08 GB Thin Size of Image
02 Concurrent Snapshots in Use
20 Desktop Pools (max. 512 desktops per pool)
157 Datastores (max. 64 desktops per datastore)
8 hosts
1 cluster

Not using Dedicated Replica Datastore: 49.06 Terabytes
Using Dedicated Replica Datastore: 2.45 Terabytes

On View 4.0 the storage consumption was linear and based on number of desktop pools and datastores created, and could reach as much as 49 Terabytes for 10,000 virtual desktops. The same scenario applied to VMware View 4.5 would only use 2.45 Terabytes.

As a remainder, each replica is created on a cluster basis, and each cluster can support 1,000 desktops according to the reference architecture (16 virtual desktops per core in an 8 core CPU). Doing the math and utilizing the 30% IOPS rule, there would be a maximum of 3,000 IOPS to be served from the replica datastore. However, you should do your own calculations based on your desktop workloads. An array of fast ESSD drives could easily provide thousands of IOPS for your VMware View environment.

If you got here I hope you probably have read the whole article. As such, I will give you a gift. My VDI calculator has been updated and now features calculation of replica storage consumption based on use of Dedicated Replica Datastore. Do your own VMware View model clicking here.

Why are you not yet using Dedicated Replica Datastores?