How to Solve ESXi 7.0 System Storage Full Issue – Free Up & Manage Space

The system storage partitioning of ESXi 7.0, among which the ESX-OSData partition occupies 120GB of storage space, which mainly serves as a unified location for storing other modules, not for booting and virtual machines. The /scratch partition, VMware Tools locker partition, and core dump target partition of old versions (versions before 7.0) are all integrated into the ESX-OS Data partition. The ESX-OSData partition reserves such a large space for future versions to add features.

Why Does ESXi 7.0 System Storage Fill Up?

When running VMware ESXi 7.0, administrators may face an error where the system storage or datastore becomes fully occupied. This issue can prevent new VMs from running, prevent snapshots from being created, or even affect host stability.

Common causes include:

Old snapshots were not deleted properly.
Large log files are consuming space in /var/log/.
Core dump files are generated after host issues.
ISO images left unused in the datastore.
Misconfigured scratch partitions or temp files.

Use the df -h command to see that the current 7.0 version of ESX-OSData partition actually only uses 2.8 GB of storage space

After installing ESXi on my 150 GB test disk, the actual space available for virtual machines is only 22 GB. If your ESXi installation disk is less than 128 GB or does not have a VMFS partition, you will need an additional storage volume to create and run virtual machines.

If you have 10 TB of storage, you might think that 120 GB is nothing, just let it be. But if your Home Lab resources are already limited, and your 300 GB storage is directly occupied by half of the system's storage space, what resources do you have left for experiments? Is there any way to reduce the system footprint of ESXi?

The answer is certainly yes, there are two solutions, one officially supported and the other unofficially supported.

Officially supported solutions

In ESXi 7.0 Update 1c, the boot option systemMediaSize was added. This option allows you to customize the space used by the system storage during ESXi installation and better match the server's purpose and size. If this option is not used, the default system occupied space is 128GB. You can use the command systemMediaSize=min/small/max to set the ESXi system storage usage space. The detailed parameters are as follows:

• min (32 GB, for single disk or embedded server)

• small (64 GB, for servers with at least 512 GB RAM)

• default (128 GB)

• max (for multi-TB servers, using all available space)

In my test environment, I used 150 GB of storage without enabling the systemMediaSize option, and ESXi 7.0 was installed by default. The system occupied 128 GB, and the VMFS Datastore occupied 22 GB. The storage partition is shown in the figure below:

The detailed steps are as follows:

1. Mount the installation image to boot the host. When the ESXi installer window appears, press Shift+O (it's the English letter O, not the Arabic numeral 0) on the keyboard within 5 seconds to edit the boot options.

2. After pressing Shift+O, you don't need to worry about the default content that appears. Just press the spacebar, then enter systemMediaSize=min/small/max, for example,systemMediaSize=min.

 
systemMediaSize=min

This will set the ESXi system storage usage to 32 GB. After setting, press Enter on the keyboard. The subsequent installation steps are the same as a normal ESXi installation.

3. After the installation is complete, check the ESXi storage partitions, as shown in the figure below:

Use the esxcli storage filesystem list command to view system storage partitions

 
esxcli storage filesystem list

Use df -h to view storage usage

Summary: When installing ESXi with a 150 GB storage disk, using the systemMediaSize=min command set the system occupancy to 32 GB, of which ESX-OSData only occupied 23.8 GB, freeing up about 100 GB of storage space compared to the previous 120 GB, and VMFS also reached 118 GB, significantly reducing the system's storage footprint.

Unofficial Solutions

The officially supported solution above can set the minimum system storage occupancy to 32 GB, but for some users, 32 GB is still too large. There is also an unofficial solution that can use the autoPartitionOSDataSize parameter to set the ESX-OSData partition size.

Disclaimer: This parameter may not be officially supported by VMware, as it deviates from official settings and may lead to other unexpected behaviors. Use at your own risk!!!

The detailed steps are as follows:

1. Mount the installation image to boot the host. When the ESXi installer window appears, press the Shift+O (that's the letter O, not the number 0) key combination within 5 seconds to edit the boot options.

2. After pressing Shift+O, ignore the default content that appears. Just press the spacebar, then enter autoPartitionOSDataSize=xxxx, for example, autoPartitionOSDataSize=8199 (unit is MB), which can set the storage usage of the ESX-OSData partition to 8GB. After setting, press Enter on the keyboard. The subsequent installation steps are the same as a normal ESXi installation.

3. After installation, check the ESXi storage partitions, as shown in the figure below:

Use the esxcli storage filesystem list command to view system storage partitions.

Use df -h to view storage usage.

Summary: Using a 150GB storage disk to install ESXi, the command "autoPartitionOSDataSize=8192" was used to set the ESX-OSData partition storage usage to 8GB. The entire ESXi system only occupies 16GB of storage space, leaving 134GB for VMFS storage, significantly reducing system storage consumption. Although this command doesn't specify a minimum value, by default, with no features enabled, the ESX-OSData partition actually occupies 2.8GB. Therefore, it's recommended not to set this value below 4096.

This article is only recommended for small Home Lab users. The default parameters have been modified, which may create some unknown risks. If used in a production environment, it may cause ESXi to malfunction. Please use with caution!

Best Practices to Prevent ESXi Storage Issues

Regularly monitor datastore usage via vCenter alarms.
Implement log rotation to prevent oversized logs.
Avoid keeping long-term snapshots on production VMs.
Periodically clean unused ISOs and temp files.
Use dedicated storage monitoring scripts with PowerCLI.

The official documentation also provides some installation parameters. Here is the official link (https://knowledge.broadcom.com/external/article?legacyId=77009)

Mobile Menu