VMware Horizon Community
jkeegan
Contributor
Contributor

Replicas on Local SSDs

I've seen a lot of talk about View deployments with using Local SSDs to store the replicas and SAN/NAS to store the linked clones, such as this post. But there isn't too much information how to actually configure such a design.

When I set out to do it I ran into an error and it doesn't look like it works like I had thought. Maybe I am misunderstanding something or maybe other folks have yet to actually try it.

I configured a pool of linked clones and placed the Replica Disks on local data store, placed the Perisitent and OS disks on seperate SAN data stores. But the pool failed to provision and displayed the error:

View Composer Fault: Invalid input parameter ReplicationDatastoreMoId for desktop provisioning. Reason: ValidationFailure

Upon googling I find KB1034259 which states "The storage location for the replica and the pool desktops must all be accessible from all the ESX hosts in the View cluster". This doesn't make any sense to me, how can the replica be located on local storage, but "be accessible from all the ESX hosts in the View cluster".

Looking at the admin guide it states the following requirements to store replicas and linked clones on in seperate data stores.

  • If a replica datastore is shared, it must be accessible from all ESX hosts in the cluster.
  • If the linked-clone datastores are shared, the replica datastore must be shared. Replicas can reside on a local datastore only if you configure all linked clones on local datastores on the same ESX host.

So if I understand this correctly you could not possibly store the replicas on a local data store and the linked clones on a SAN/NAS. Unless the LUN/Share was only aviable to a single ESX server (i.e. it was not shared).

Looking at VMware's Reference Architecture for Stateless Virtual Desktops on Local Solid-State Storage with VMware View 4.5 they store both the replica and linked clone on the local storage, so maybe it's not possible.

So I am confused and hope the community can help me out.

Can you store the replica on local SSD and the linked clone on shared SAN/NAS?

Thanks,

Joe

Reply
0 Kudos
6 Replies
mittim12
Immortal
Immortal

My answer to the question is no you can't do it.  The linked clone is based on the replica and needs access to the replica.  I don't see how it's possible to have the linked clones on the SAN running on multiple ESX host accessing a replica on the local SSD of one of the ESXi host.

Reply
0 Kudos
npeter
Expert
Expert

Replica can be stored on Local SSD when pools are deployed on a single/standalone esx host.

In case of esx cluster, if you select a local datastore of one of the esx in a cluster for clones; and local SSD for repica, it will result in error since a DRS cluster can place vms in any one of the host during deployment and selected datastore may not be accessible from that host.

-noble

-nObLe
Reply
0 Kudos
mittim12
Immortal
Immortal

IMO that type of configuration is best suited for environments that have no need for DRS/HA and do not want to utilize their SAN infrastructure.  

Reply
0 Kudos
npeter
Expert
Expert

I agree with that.  many peaople get confused with the documentation. They try to use local disks in clustered env and end up in error state.

-nObLe
Reply
0 Kudos
jimeece
Contributor
Contributor

I tried the same thing and had the same result. While I certainly agree there is merit to completely going without shared storage - particularly in a stateless model - I wanted to understand how this could be done. the only way that I'm aware of is to follow something like this pdf outlines. A friend of mine did something similar, but this paper provides better detail. The key is to build a virtual SAN.

JM

Reply
0 Kudos
Dave_McD
Contributor
Contributor

Shouldn't the advent of 5.1 with the ability to vmotion from one local datastore to another resolve this problem? We bought 2 local SSD drives with 5.1 with the intent of using them to host our replicas.

When I try and set the replica drive to one of the SSDs, I get the above error.

Reply
0 Kudos