VCP related studies - Memory in VMWARE reservations, limits and memory overcommit.

Hey Guys
--------------- VCP Rant -------------------------------
I might have to rename this blog to VCPRants soon enough :) I am busy chasing my VCP or VMWare certified Professional,

Cisco Guys, let me tell you that your highly likely to run into Vmware sooner than you think. The new UC on UCS stratergy from cisco means that all unified communications products will soon be running under VMWare.

With this in mind, I wanted to make sure I understood VMWare very well, so I can do the best possible job with the next generation UC.

This blog article will be the first in a series on VMWare, these blog posts do assume you at least have some rudimental knowledge on what virtual machines are and a reasonable understanding of what ESX is
----------------------------- End Rant -----------------

Now onto business, this blog article is going to talk about Memory in VMWare.

ESX/ESXi is the only commercially available hypervisor that I am aware of (please leave a comment if you know otherwise!) that supports memory overcommit, or the act of provisioning more memory for virtual machines than a host actually has.

Lets take a quick example, I have an ESX Host, HostMachine, this HostMachine has 4 gig of ram, if i want to create four virtual machines, each assigned 1 gig of ram, without memory overcommit, i could only provision 4 virtual machines (in reality, it would be slightly less than 4 gig of ram available to my virtual machines because of ESX overheads but lets ignore that for a minute.)

With memory overcommit, vmware allows you to overcommit memory, so in our example above , we could create 8 hosts, each with 1 gig of memory assigned and run all 8 of them at the same time. ESX looks after memory usage using three key technologies:

1. Idle Page Reclamation
this technology reclaims any idle pages in memory and allows other virtual machines to use them
2. Transparent Page sharing
if two virtual machines have the exact same memory contents in a particular memory page, this single page will be shared amongst both the virtual machines (lets say for example, two virtual machines running the exact same version of windows, probably quite a few bits of memory that are going to contain exactly the same information)
3. Ballooning
This feature relies on vmware tools being installed on the guest OS, but allows Vmware to tell the vmware tools driver on the guest OS to start grabbing memory, it can then return that memory to the ESX host and the ESX host can then allocate it to other virtual machines in a process called "inflation", memory can be returned when not needed using a process called, you guessed it: deflation.

My favorite tech of the above is definitely ballooning, what a brilliant idea.

Ok, so now you know how VMWare can share and overcommit memory, what about controlling access to memory, after all, memory is a finite resource. Plus what happens when there is simply no other memory available?

Well VMware uses swap file memory, much like windows, in the event that no physical memory is actually available. This .vswp extension file sits by default in the same directory as all the other files for the vmware machine. Its size is the same size as the memory allocated to the virtual machine, so in our example above the machines would have 1 gig swap files. This file is used as a last resort should there litreally be no other memory available to be used even with the three technologies mentioned above.

But Disk is slow! Incredibly slow compared to ram, up to 800,000 times slower. So how can you ensure your important mission critical virtual machines can be allocated REAL physical RAM rather than being paged onto this swap file? The answer in VMWARE is reservations and limits.

Go to Edit Settings under your virtual machine then to resources, then memory. You will see you can set reservations and limits, by default the settings are
reservations: 0 MB
Limit: Unlimited

Reservations control how much physical RAM _must_ be available to the Virtual machine before it will even be allowed to turn on. This ensures that the machine has an acceptable amount of memory available before it will boot. it also ensures that no other virtual machines can en-roach upon this memory. So for our example, lets say of our four virtual machines one of them is our ARC Attendant Console server, its mission critical so we want to ensure it gets at least 512 MB of physical RAM, we set the reservation to 512.

Limit controls how much of the memory assigned to the virtual machine can actually be physical memory. So for example, if on our ARC server we decided that the machine needed no more than 768 MB of memory, but might occasionally burst to 1 gig, we could set the limit to 768. THis means that once the virtual machine is using 768 meg of physical memory, any additional memory it needs over and above this to its configured memory limit (1 gig) will be stored on the swap file.

So Reservation guarantees that the virtual machine will be allocated at LEAST that amount of physical memory, the limit sets a limit to how much physical ram the virtual machine can have before it has to start using swap file and the configured memory is how much memory the OS can actually use.


I hope this helps a studying VCP out there!