Dave_McD
Contributor
Contributor

Replicas on local SSDs and OS on Shared storage, View 5.1

Jump to solution

If we have the functionality to vMotion betoween local datastores, why can't we use the same functionality for local SSD's for VMware View?

I am getting the following error which I am finding very frustrating.

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

0 Kudos
1 Solution

Accepted Solutions
mittim12
Immortal
Immortal

The obvious difference between the two is the fact that the replica is being hit with a steady stream of IO from the clones where as the new vMotion isnt constant.   Also, if I'm not mistaken it's limited to the same number of concurrent migrations as vMotion or Storage vMotion.

View solution in original post

0 Kudos
2 Replies
mittim12
Immortal
Immortal

The obvious difference between the two is the fact that the replica is being hit with a steady stream of IO from the clones where as the new vMotion isnt constant.   Also, if I'm not mistaken it's limited to the same number of concurrent migrations as vMotion or Storage vMotion.

0 Kudos
Dave_McD
Contributor
Contributor

Yes, that makes sense and I knew that anyway, I guess I am just venting my frustration.

I now have the situation where we have local SSD on the 2 hosts in the cluster and both fibre shared storage and SAS shared storage.

What is the best use of this environment to give speed and redundancy?

I am thinking to have the desktops including persistent and disposable disks on the SSD's with the replica on fibre shared. My thinking is that if we have a host outage the replica will be able to provision the lost desktops on the other drive?

0 Kudos