![datastore usage on disk alarm in vsphere 7 datastore usage on disk alarm in vsphere 7](http://blog.icewolf.ch/images/blog_icewolf_ch/202105/VCSA_6.7.0U3n_04.jpg)
![datastore usage on disk alarm in vsphere 7 datastore usage on disk alarm in vsphere 7](https://4sysops.com/wp-content/uploads/2019/09/VMware-SDRS-settings-600x401.png)
![datastore usage on disk alarm in vsphere 7 datastore usage on disk alarm in vsphere 7](https://www.lazynetadmin.com/wp-content/uploads/2021/05/vcenter-clone-screenshot3-1024x641.png)
In the next version of vCenter I do hope VMware makes a change and enables the use of GB on this alarm instead of just a percentage. I should warn you though… my friend Duco Jaspars tipped me about this KB article: “ Defining alarms on datastore folders can cause vCenter Server 4.x to becomes unresponsive“, although I have not yet ran into this issue with the customers were I implemented this. See how the next image gives you much less alarms and only shows warnings and alarms on datastores that really are below 40GB. The alarms you see are now “real” alarms that really require your attention. This will give you a much better view of your datastores and alarms. There is an easier way, you can create folders and assign alarms to folders and move datastores of the same size into these folders. Unfortunately in most environments, not all datastores are equal in size and you would have to change the alarm on each datastore.
#Datastore usage on disk alarm in vsphere 7 free
Those 40GB free space I would like to monitor through my vCenter alarms which is very easy if all datastores would be equal in size, you could than edit the default alarm to reflect the new % settings. Usually these 40GB can accomodate enough snapshot space during nightly backups and storage migrations to prevent the datastore from filling up. In general I use as a rule of thumb a required free space per datastore of 40GB. In most cases this is much too soon as the next image shows you. These false alarms happen because the default values right out of the box are set at 75% for a warning to trigger and 85% for an alarm to trigger. When I show them the datastore overview in the VI Client that shows the warnings and alerts for the datastores, it turns out that they don’t often look at this page because it gives too many false alarms. The 13th disk is used for the /storage/archive volume.When visiting customers I noticed that the VMware admin often doesn’t really know how much free space is left on the datastores and wether action is needed to free up space or get extra capacity. In vSphere 6.5, the vCenter Server Appliance has 12 vDisks, in vSphere 6.7, this has increased to 13. Verify the vCenter Server Appliance VAMI Health Status for Storage is “Good”.After some time has passed, verify the vSphere Client System Configuration Node Health is “Good”.Run the “df -h” command and verify the “/storage/archive” mount Use percentage has decreased.In the SSH session to the vCSA, run the autogrow script “/usr/lib/applmgmt/support/scripts/autogrow.sh”.Access the vCenter Server that the vCSA instance is running on and increase Disk 13 of the vCSA VM Hardware by a significant amount.Run the “df -h” command and verify the “/storage/archive” mount is at 90+% of use.SSH into the vCSA and login as root and execute the “shell” command to get shell access.
#Datastore usage on disk alarm in vsphere 7 how to
VMware has not created an updated KB article explaining how to remediate this particular issue.Increase the size of the disk /storage/archive.” Access this page from Summary, Health Status. vCenter Server Appliance VAMI Health Status reports an Alert for Storage: “File system /storage/archive is low on storage space.Login to vCenter Server Appliance VAMI: :5480.Access this page from Administration, Deployment, System Configuration. vSphere Client System Configuration reports Node Health is Degraded.vCenter Server Appliance 6.7 deployed and in use.The workaround detailed below may not be supported, so implement it at your own risk. Update: This KB indicates VMware Engineering is aware of the issue and has been fixed. This post is applicable to customers using the VMware vCenter Server Appliance (vCSA) 6.7.