Minimizing the vCenter memory footprint – Windows

With vSphere 5.1 the memory requirements of the vCenter server have dramatically increased. If all components reside on a single Windows server [VM], even the smallest inventory size will require 10 GB of memory, according to the VMware Installation and Setup guide. Although this document states a minimum of 4 GB memory for the vCenter Appliance, it is in fact configured for 8 GB RAM after deployment. This will most likely exceed or significantly reduce the resources of small home labs or all-in-one setups with VMware Workstation.

Is this necessary? Nope. But due to the default JVM memory settings a simple reduction of the VMs’ RAM could lead to swapping and have a negative impact on the overall performance, obviously. The following adjustments to the application settings will allow to reduce the VM memory to 4-5 GB. This posting covers a Windows-based vCenter server, the following post will be related to the Appliance.

No need to mention that all of this is absolutely not supported by VMware, right?

Prerequisites:
The vCenter server is installed on a Windows 2008 R2 server VM with SQL Server 2008 R2 Express and no noteworthy additional software or roles. The SQL Server setting “Maximum server memory” has been configured for a low value – 256 MB should be fine.

After installation of the vCenter Server components edit the following files and change the settings:

Single Sign On:

  • C:\Program Files\VMware\Infrastructure\SSOServer\conf\wrapper.conf
  • Set wrapper.java.additional.9=”-Xmx” (default: “1024M”) to “256M”
  • Set wrapper.java.additional.14=”-XX:MaxPermSize=” (default: “512M”) to “128M” (or half of the Xmx value chosen before)

Inventory Service:

  • C:\Program Files\VMware\Infrastructure\Inventory Service\conf\wrapper.conf
  • Set wrapper.java.maxmemory (default: “3072”) to “384” (MB)

Tomcat:

  • C:\Program Files\VMware\Infrastructure\tomcat\conf\wrapper.conf
  • Set wrapper.java.additional.9=”-Xmx” (default: “1024M”) to “512M” – “768M”
  • Set wrapper.java.additional.14=”-XX:MaxPermSize” (default: “256M”) to half of the Xmx value chosen before

Web Client:

  • C:\Program Files\VMware\Infrastructure\vSphereWebClient\server\bin\service\conf\wrapper.conf
  • Set wrapper.java.initmemory (default: “1024m”) to “256m”
  • Set wrapper.java.maxmemory (default: “1024m”) to “384m”

Log Browser:

  • C:\Program Files\VMware\Infrastructure\vSphereWebClient\logbrowser\conf\wrapper.conf
  • Set wrapper.java.maxmemory (default: “512”) to “256” (MB)

Profile Driven Storage:

  • C:\Program Files\VMware\Infrastructure\Profile-Driven Storage\conf\wrapper.conf
  • Set wrapper.java.initmemory (default: “256”) to “128” (MB)
  • Set wrapper.java.maxmemory (default: “1024”) to “384” (MB)

Orchestrator:

  • C:\Program Files\VMware\Infrastructure\Orchestrator\app-server\bin\wrapper.conf
  • Set wrapper.java.additional.3=-Xmn (default: “768m”) to “256m”
  • Set wrapper.java.initmemory (default: “2048”) to “384” (MB)
  • Set wrapper.java.maxmemory (default: “2048”) to “512” (MB)

The latter two values must be higher than the Xmn value chosen before.

This settings are the lowest value I have personally used without experiencing any problem in an environment of two ESXi hosts and about three dozen VMs with half of them up & running, the other powered off or templates. To be perfectly honest I did not try to find out the absolutely lowest possible settings – the result of the first shot were satisfying enough, cutting the RAM requirements in half and thus roughly back to pre-5.1 times.

If you do run into problems, either regarding performance or even functionality, please post a comment and the parameter & value you changed to resolve it.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

code