So this next post is about my experience with vSAN when using multiple storage policies and the headache that comes with managing a large vSAN environment when you have too many cooks in the kitchen!!

The environment I help manage has many clusters with many different storage policies… Unfortunately the storage policy “Compliance” status can be misleading and risky at scale especially if that’s all your depending on for desired / expected state of VM storage policy.

Recently we discovered that VM Home directories and VMDKs would end up with a mix and match of police’s if the administrators were not careful when moving, cloning and adding / changing disks! (basically BAU activities)

For example in our configuration we have 1 storage policy per vSAN cluster and depending on the requirement of the customers VM’s … they end up on a specific cluster with a specific storage policy (FTT=1, FTT=2, RAID1, RAID5/6 with Erasure Coding…etc)… now when we looked in the vCenter GUI all the VM’s were showing up as compliant with the storage policy which was great!!! but when we started to dig deeper we found out that VM’s were at risk because some disks would only tolerate 1 host failure where as others would tolerate 2 host failures some were on RAID1 and others on RAID5/6 with EC…!!!!

To manage / report correctly on the desired state and compliance of VM’s I built this report on my home lab (see below), it checks every single VM, it’s home directory and each VMDK and pumps the results out to a CSV.

So while the report above is useful… when you have 1000’s of VM’s to manage some additional logic and checking is required… Currently I visualise this data in Tableau by merging it with some inventory data…. but now I am working on improving this report further by validating against a configuration file that contains the expected policy for that Cluster / Datastore and identifying VM’s with issues (outOfDate, nonCompliant or compliant with the wrong policy for its location)

2 silly things which I discovered while on this adventure…

1). It appears there is no way to extract the current default vSAN policy via PowerCLI or the API… the only way I could do it was by creating a VM on a datastore and then checking what policy it got

2) The default vCenter Read Only role does not have sufficient permissions to run the command get-SpbmEntityConfiguration you need an additional permission for the user: Profile-driven storage view

so to the script!

To create the credentials file run the following command.

To run the script..

Main script