vPivot

Do you have any running instances of ESX 3.5 or older?  Are those instances running on processors that are no more than a couple of years old?  If so, I have a tip for you: update your hosts to ESX 4.0. Seriously, upgrade to vSphere already. It’s been out for a year!

All kidding aside, yesterday I wrote an article about a sneaky trick to leverage improved hardware assist performance on ESX 3.5 virtual machines that defaulted to binary translation. I learned very late in the day that the recommended guidance only works for AMD processors. The text below is from the original post but has since been updated to reflect my newly discovered information.

Begin Updated Article

Do you have any running instances of ESX 3.5 or older?  Are those instances running on AMD processors that are no more than a couple of years old?  If so, I have a tip for you: force hardware assist in those virtual machines.  In most situations application performance will improve by 10% or more.  Details follow.

ESX’s monitor presents virtual hardware to virtual machines’ guest operating systems.  VMware’s multi-mode monitor uses three technologies to do this: hardware assist, para-virtualization, and binary translation.  Hardware assist has gotten much faster over the years, as this figure demonstrates.

The latency of the VMEXIT instruction is shown on Intel VT systems. The longer this instruction takes to execute, the worse the virtual machine performs.

Johan De Gelas included his take on monitor mode performance when he reported “Virtualization Round Trip Latency” in a recent article on the new Xeon 5600.  His results reiterate the trend I have been sharing with my audiences for over a year now.

Because hardware assist was once so slow, older versions of ESX would utilize our faster-performing binary translation in many situations.  But virtualization assist in today’s processors–and here I am talking about Intel and AMD processors manufactured in the past two years–is generally faster than binary translation. This means your virtual machines running on ESX 3.5 on shiny new processors may not be reaching their full potential performance.

The fix is simple: force hardware assist for your ESX 3.0 and ESX 3.5 virtual machines running on newer AMD processors.  You can do this with the following lines in your virtual machines’ VMX files:

monitor.virtual_mmu = hardware

A reboot is then required. But this setting only works for AMD processors, where RVI (AMD’s hardware memory management unit) is available. With this setting both AMD-V and RVI are forced on. This setting is ignored on Intel processors, whose hardware MMU is not leveraged on ESX 3.5.

These changes are not needed with vSphere because its default monitor modes favor hardware assist more than ESX 3.5 and earlier. You can see vSphere’s default monitor modes in our wonderful monitor modes paper.

As one example of the magnitude of performance increase this small change can produce, look to the SQL Server performance paper we released last year.  Here is one graph I lifted from that document.

This figure shows AMD-V improving performance by 18% over binary translation on virtual machines running SQL Server 2008.  More gain is possible when the hardware memory management unit is utilized.

Because of ESX 3.5′s continued wide deployment, it may very well be running millions of virtual machines.  Many those virtual machines are running on newer AMD processors that can benefit from this change.  Go forth and reconfigure those virtual machines to claim the performance to which you are entitled!