The VMware vSAN community grows fast and we see more and more of our customers to integrate our vSAN plugin into Performance Analyzer.

Based on great feedback and some interesting findings we updated and added some of our dashboards to show storage histogram profiles per VM and also to calculate current and future vSAN memory consumption. Especially the memory consumption is not clear to every customer and we wanted to show real numbers.

Lets start with the VMware vSAN memory consumption, what it is, how its calculated and why its a topic.

The amount of Memory of required overhead is mandatory and cannot be avoided and shouldn’t be reduced to maintain optimized performance. Memory overhead is something known for any virtual storage system and just the amount varies. The biggest difference when it comes to vSAN is, that you don’t see the memory consumption as a task, process or virtual machine. When a virtual storage solution runs virtual machines, the memory usage can simply be checked at the virtual machine level – that’s the big difference.

It’s important when designing a VMware vSAN environment to keep the memory consumption in mind. When running a home lab that amount can be painful.

There is a very good VMware KB article about it: https://kb.vmware.com/s/article/2113954

You definitely want to avoid shortcomings when using vSAN  https://kb.vmware.com/s/article/2071753

The KB article describes the formula to calculate the memory consumption to run vSAN in a proper way as the involved components 

To calculate vSAN memory consumption in these releases, use this equation:

BaseConsumption +(NumDiskGroups * (DiskGroupBaseConsumption + (SSDMemOverheadPerGB * SSDSize))) +(NumCapacityDisks * CapacityDiskBaseConsumption)


  • BaseConsumption: is the fixed amount of memory consumed by vSAN per ESXi host.
  • NumDiskGroups: is the number of disk groups in the host, this value should range from 1 to 5.
  • DiskGroupBaseConsumption: is the fixed amount of memory allocated to each individual disk group in the host. This is mainly used to allocate resources used to support inflight operations on a per disk group level.
  • SSDMemOverheadPerGB: is the amount of memory allocated per GB of SSD.
  • SSDSize: is the size of the SSD disk in GB.
  • NumCapacityDisks: is the number of capacity disks in the host (across all the diskgroups).
  • CapacityDiskBaseConsumption: is the amount of memory allocated per capacity disk.

Note: The size of the SSD for all flash is capped at 600GB, and thus using SSDs larger than 600 GB will not consume additional memory.Constants

  • BaseConsumption = 5426 MB
  • DiskGroupBaseConsumption = 636 MB
  • SSDMemOverheadPerGB (hydrid) = 8 MB
  • SSDMemOverheadPerGB (allflash) = 14 MB
  • CapacityDiskBaseConsumption= 70 MB

Note: In these releases, encryption and deduplication features have no impact on memory consumption.

Bad thing – who wants to sit down and calculate numbers. Therefore, we created a dashboard to do that calculation for you and visualize it in a nice way. Furthermore, you can switch between Hybrid and All Flash calculation – the dashboard is called VMware vSAN: Capacity and Balancing. It shows the distribution of all vSAN Nodes.

vSAN memory consumption

Another important topic we spent development time is the Storage profile histograms. It allows you to check the storage profile of your systems. More read, more write, what block size. That helps when planning for storage upgrades.

VMware vSAN Histogram

Independent if you’re using VMware vSAN or any other storage system and you need to get a storage profile of a datastore, single virtual machine or a complete cluster – make sure to check out our latest integration that brings vSCSIstats into Performance Analyzer.

Here comes a single VM:

VM storage profile

Here comes the datastore view:

VMware datastore profile

Just make sure to follow our guideline how to activate our vSCSIstats collector.


Since vscsiStats consumes some host resources itself, it is not recommended to have it running all the time. But it is very helpful, if you have to troubleshoot storage performance.

To enable the Performance Analyzer vSCSIstats collector, Just add a custom attribute "opvizor.vscsistats" to the host(s) you want to monitor, and set it to 1 to start data collection. Set it to 0 to stop data collection. 

If you want to learn more about vSCSIstats check that blog post: http://buildvirtual.net/using-vscsistats-to-gather-storage-performance-data/

Metrics and Logs

(formerly, Opvizor Performance Analyzer)

VMware vSphere & Cloud

Monitor and Analyze Performance and Log files:
Performance monitoring for your systems and applications with log analysis (tamperproof using immudb) and license compliance (RedHat, Oracle, SAP and more) in one virtual appliance!

Subscribe to Our Newsletter

Get the latest product updates, company news, and special offers delivered right to your inbox.

Subscribe to our newsletter

Use Case - Tamper-resistant Clinical Trials


Blockchain PoCs were unsuccessful due to complexity and lack of developers.

Still the goal of data immutability as well as client verification is a crucial. Furthermore, the system needs to be easy to use and operate (allowing backup, maintenance windows aso.).


immudb is running in different datacenters across the globe. All clinical trial information is stored in immudb either as transactions or the pdf documents as a whole.

Having that single source of truth with versioned, timestamped, and cryptographically verifiable records, enables a whole new way of transparency and trust.

Use Case - Finance


Store the source data, the decision and the rule base for financial support from governments timestamped, verifiable.

A very important functionality is the ability to compare the historic decision (based on the past rulebase) with the rulebase at a different date. Fully cryptographic verifiable Time Travel queries are required to be able to achieve that comparison.


While the source data, rulebase and the documented decision are stored in verifiable Blobs in immudb, the transaction is stored using the relational layer of immudb.

That allows the use of immudb’s time travel capabilities to retrieve verified historic data and recalculate with the most recent rulebase.

Use Case - eCommerce and NFT marketplace


No matter if it’s an eCommerce platform or NFT marketplace, the goals are similar:

  • High amount of transactions (potentially millions a second)
  • Ability to read and write multiple records within one transaction
  • prevent overwrite or updates on transactions
  • comply with regulations (PCI, GDPR, …)


immudb is typically scaled out using Hyperscaler (i. e. AWS, Google Cloud, Microsoft Azure) distributed across the Globe. Auditors are also distributed to track the verification proof over time. Additionally, the shop or marketplace applications store immudb cryptographic state information. That high level of integrity and tamper-evidence while maintaining a very high transaction speed is key for companies to chose immudb.

Use Case - IoT Sensor Data


IoT sensor data received by devices collecting environment data needs to be stored locally in a cryptographically verifiable manner until the data is transferred to a central datacenter. The data integrity needs to be verifiable at any given point in time and while in transit.


immudb runs embedded on the IoT device itself and is consistently audited by external probes. The data transfer to audit is minimal and works even with minimum bandwidth and unreliable connections.

Whenever the IoT devices are connected to a high bandwidth, the data transfer happens to a data center (large immudb deployment) and the source and destination date integrity is fully verified.

Use Case - DevOps Evidence


CI/CD and application build logs need to be stored auditable and tamper-evident.
A very high Performance is required as the system should not slow down any build process.
Scalability is key as billions of artifacts are expected within the next years.
Next to a possibility of integrity validation, data needs to be retrievable by pipeline job id or digital asset checksum.


As part of the CI/CD audit functionality, data is stored within immudb using the Key/Value functionality. Key is either the CI/CD job id (i. e. Jenkins or GitLab) or the checksum of the resulting build or container image.

White Paper — Registration

We will also send you the research paper
via email.

CodeNotary — Webinar

White Paper — Registration

Please let us know where we can send the whitepaper on CodeNotary Trusted Software Supply Chain. 

Become a partner

Start Your Trial

Please enter contact information to receive an email with the virtual appliance download instructions.

Start Free Trial

Please enter contact information to receive an email with the free trial details.