Skip navigation
drummonds Hot Shot

The Role of the ESX Monitor

Posted by drummonds Apr 29, 2009

There's a lot of confusion out there on VMware's support for the CPU vendors' virtualization assist technology.  VMware has always led the industry with its support for hardware assist.  We were the first vendor to support AMD-v and Intel VT-x in 2006, the first to support AMD RVI in 2008, and will be the first to support Intel EPT when vSphere 4 becomes publicly available.  These technologieswhich we call hardware assistprovide value to the part of ESX we call the monitor.


As we prepare for vSphere's general availability we're generating a lot of documentation to help people get the most out of the new version of ESX.  One of my colleagues started a document that details the role of the monitor and how it flexibly uses different hardware assist technologies.  I've summarized the default behavior of our monitor in several situations in ESX Monitor Modes.  Of course vSphere's users will be able to override these defaults if they want to experiment with their workloads.


I wanted to include a textual summary of the role of the monitor in virtualization but found myself getting bogged down with the writing.  So, I thought I'd try something new.  Let me know what you think of this short video clip explaining the role of the monitor and how it might leverage hardware assist.


I recently attended a practice talk for next week's Partner Exchange hosted by Kit Colbert, one of our senior engineers, who is leading a whole bunch of cool efforts around performance.  I wanted to "leak" one slide that his showed us that we'll be touching up for publication.  Some of you that are curious about memory counters and want a different take from Memory Performance Analysis and Monitoring may find this interesting.



Some of this stuff won't make sense outside of Kit's presentation, but let me point out a few things that may help consume the information in this incredible chart:


  • One of the key messages from Kit's presentation is that ESX reports memory with respect to the guest (the VM) and the host.  The very top rectange shows memory stats reported for each VM.  The second rectangle shows the single VM's memory stats reported by each host.

  • As can be seen from the above, the consumed memory in the host represents everything in the VM, minus the savings due to page sharing.

  • This graph doesn't yet highlight the difference between ballooned memory and swapped memory from the guest perspective.  From the guest's perspective, swapped memory is much more attractive then ballooned memory, as the guest doesn't know that the swapped memory is gone.  But it does see the ballooned memory as pinned.  ESX is clever enough to deflate the balloon driver, if possible, when the guest starts to access swapped memory to avoid the host's swapping of guest memory.

  • The final rectangle shows memory of all VMs from the host's perspective.  Don't pay attention to the reserved and unreserved memory; I'm told those are unnecessary distractions that will be removed.


Kit is going to be in Orlando with me next week to talk about ESX and guest memory management.  He's going to explain the difficult process of recovering unused memory from guests to enable over-commitment.  Be sure and see him if you're in town!