Archive for : February, 2011

Virtual Machine Memory Overhead

Windows virtual machines require more memory with each passing release and software demands on memory are becoming larger all the time.  In a vitual environment it is quite simple to increase the amount of virtual memory granted to a virtual machine, especially with features such as hot add.  The ability to dynamically increase the amount of memory available to the virtual machine whilst it is still turned on.

Hot add has a few requirements.
From a licensing point of view you need vSphere Advanced, Enterprise or Enterprise plus as a minimum.
The chart below illustrates the Windows Operating Systems that support Hot Add.

* Server must be rebooted for memory to be registered in Windows.

Adding additional RAM to a virtual machine is so easy these days that it is important to not over look the effects that increasing the virtual machine memory can cause on the host and the virtual machine datastore.
Every Gigabyte of virtual machine memory demands more memory overhead from the ESX host.  The overhead on the host is illustrated in the table below.

As you can see, the total amount of RAM the hosts requires to power your virtual machines and future ones can increase dramatically when you start adding more RAM to your virtual machines, especially when adding more vCPU’s.  This is also true with the multi-cored vCPU in vSphere 4.1, as explained by Jason Boche.

To put this into perspective, if you have a  host with ESX installed with two virtual machine running 2 VCPUs and 4GB RAM each you would need to allow 10.1GB RAM as a minimum.

1.6GB (ESX)+ 4GB (VM1)+ 242.51MB (Overhead VM1)+4GB (VM2)+ 242.51MB (Overhead VM2)=10.1GB

Depending on the load on the virtual machines, they may require up to the full 4GB assigned to them, this leaves no additional memory available.  This is not something I would recommend.  I would instead assign at least 12GB to this configuration, more likely more so that there is room for expansion at a later date, or adding additional virtual machines.

Storage is another consideration when upping the amount of virtual machine memory.  The virtual machine swap file, .vswp, is equal to the size of the virtual machine RAM installed. Ensure this is taken into account when thinking about what size datastore is required to store the virtual machines.  The alternative is to specify a seperate, fast access datastore for storing the virtual machine swap file.  If possible use SSD drives.
This can be set by following the instructions for Storing a virtual machine swap file in a location other than the default on the VMware website.

With careful planning, running out of memory or storage should never happen if you follow VMware best practices for creating virtual machines.  More information can be found in the vSphere 4.1 Performance Best Practices guide.
Additional information on VMFS datastore storage allocation can be found here

Windows Server 2008 Enterprise x64 a
Windows Server 2008 Enterprise x86 a
Windows Server 2008 Standard x64 a *
Windows Server 2008 Standard x86 a *
Windows Server 2003 Enterprise x64 a
Windows Server 2003 Enterprise x86 a
Windows Server 2003 Standard x64 x
Windows Server 2003 Standard x86 x

VMFS Datastore Free Space Calculations

As technology progresses, storage requirements grow.  It seems to be a never ending pattern.  I remember only a few years ago the maximum configurable LUN size of 2TB seemed huge.  Now it is common to have many LUN carvings making up tens of Terabytes of SAN storage.
The downside to all this extra storage is demand for larger virtual machine disks then you find that the VMFS datastores get filled up in no time.
This is something we are all aware of , and it is something we can avoid with enough planning  done ahead of time.   (Preventing it filling up not stopping demand for more space that is!)

Before adding any additional virtual machine drives it is important to ensure that enough free space is available for the virtual machines already setup.
In order to calculate the minimum free space required  use the following formula courtesy of ProfessionalVMware.

(Total Virtual machine VMDK disk sizes + Total Virtual Machine RAM Sizes * 1.1)*1.1 + 12GB

This formula can be used to work out what size the VMFS datastore needs to be. Once you work that out you can deduct this from the total available space on the VMFS datastore to see how much space can be used for additional drives without resorting to just adding disks until the vSphere Server complains it is running out of free space.

This will allow enough for the local installation of ESX(i) and an additional 10% for snapshots, plus an additional 10% for overhead.  (12GB for an ESXi install is a little excessive but I would still recommend leaving this much space as it will be required before you know it.)

ProfessionalVMware have provided this handy excel spreadsheet for working this out for you.

This formula can prove useful when planning how much storage space is required when performing a P2V migration.  This way you can be sure to manage expectations so that you are fully aware from the beginning how much free space you have available in the VMFS datastore.
This is a recommended minimum, you may need to leave more free space depending on the requirements.  ISO files, templates etc will also need to be taken into account.

Following the calculations you may find that the requirements for free space has been met but you are getting alarms in the vSphere Client saying you are running out of free space.
The alarms within the vSphere client are set to send a warning alert you when 75% of the datastore is in use, and an error when 85% is in use.
This can be adjusted if required by clicking the top level and selecting the alarms tab within the vSphere client.