I’ve been experimenting with vSphere’s memory hot add and CPU hot plug features to determine its usefulness with Windows Server operating systems. I came up with mixed results depending on the version and architecture of the OS.
A few notes about the results:
- Memory hot remove is not supported at all by vSphere. It’s not an option no matter what the guest OS.
- Although virtual hardware can be hot added depending on the OS, there are caveats in certain cases
- A guest reboot may be required (this is outlined in the table below).
- Memory that is hot added to guests that support the hot add without a reboot will result in 100% sustained CPU utilization in the guest OS for a variable period of time that is dependent on the amount of of memory that is added. In my testing (and keep in mind your mileage may vary on different hardware):
- 1GB of RAM hot added resulted in 100% CPU for 1-3 seconds.
- 3GB of RAM hot added resulted in 100% CPU for about 10 seconds.
- CPU hot unplug is supported by vSphere but was not supported by any of the Windows operating systems that I tested.
- Going from 1vCPU to 2vCPUs in Windows 2008 guest operating systems did not result in a HAL change. From what I can tell, Windows 2008 uses the same HAL for uniprocessor and SMP. When a vCPU is hot added, it does show up right away in the Device Manager, however, it’s not seen in Task Manager or Computer Properties therefore my assumption is that processes are not being scheduled on the added vCPU until after the reboot at which time the additional vCPU shows up in all places that it should (ie. Task Manager, Computer Properties, etc.)
- I certainly like the innovation and flexibility here but I’m not sure hot add technology is going to mesh well with planned change management systems. The most important thing to recognize though is that VMware offers this technology to us as our choice to use or not use. It’s not a feature VMware held back drawing their own conclusion that nobody on the planet could ever use it. Microsoft does this today with Hyper-V memory over commit. Or rather they don’t offer memory over commit in Hyper-V because they made the decision on behalf of all their customers that nobody could or should use memory over commit. Instead you should pad your hosts with more physical memory at additional cost to you.
Here is the table of results I came up with:
|Windows Server 2003 STD x86|
|Windows Server 2003 STD x64|
|Windows Server 2003 ENT x86|
|Windows Server 2003 ENT x64|
|Windows Server 2008 STD x86||*|
|Windows Server 2008 STD x64||*||*|
|Windows Server 2008 ENT x86|
|Windows Server 2008 ENT x64||*|
|Windows Server 2008 DC x86|
|Windows Server 2008 DC x64|
|Windows Server 2008 R2 DC x64
(experimental support only)
|* Reboot of guest OS required to recognize added hardware|