On a stretched vSAN 7.0.3 cluster (4+4) we're getting Skyline warnings concerning vCLS VMs.
"VM storage policy is not-recommended"
The vCLS VMs are using the "vSAN default storage policy", which is indeed not recommended.
I wonder what would be a good (and sensible) policy for vCLS?
Our "production" policy (site mirroring, FTT1-RAID1) would be a bit too much, because all 3 vCLS offer intrinsic redundancy.
We've got another policy for testing VMs (site mirroring, no data redundancy), which seems more suitable to me.
Don't get me wrong, a RAW datastore footprint of less than 3 GB isn't worth mentioning. 😉
This is more a principle question on how to treat vCLS on stretched clusters.
Do we need any DRS rules to spread them? (vCenter is on a distinct management cluster)
Any recommendations?
TIA
Michael
I would just recommend to replicate them, and don't bother with VM-Host rules. First, I don't know we even support the use of those rules. Second, vCLS VMs can be reprovisioned by EAM, which means the rules wouldn't work after the reprovisioning as it would be a new VM. Just keep it simple.
I would just recommend to replicate them, and don't bother with VM-Host rules. First, I don't know we even support the use of those rules. Second, vCLS VMs can be reprovisioned by EAM, which means the rules wouldn't work after the reprovisioning as it would be a new VM. Just keep it simple.
Thanks Duncan.
I see, thats true. A new VM Object would get a new ID and render an existing DRS rule useless.
So a stretched policy with no local redundancy should do the job.
In the meantime I found the reason why these apps (and other VMs) got the wrong policy.
The vSAN datastore's default policy wasn't set to a stretched policy.
Thanks
Michael
yeah we tend to see that a lot, this is why in vSAN 8 we introduced "auto policy management", which provides suggestions to improve the default policy to align with the configured services.