In
my previous blog I mentioned the term VM Sprawl and this is where Idle VMs are likely to factor.
Often
VMs are provisioned to support short term projects, for development/test processes or for applications
which have now been decommissioned. Now idle,
they’re left alone, not bothering anyone and therefore not on the Capacity and
Performance teams radar.
Which brings us back to the question. Idle VMs - Why should we care?
We should care, for a number of reasons but let's start
with the impact on CPU utilization.
When VMs are
powered on and running, timer interrupts have to be delivered from the host CPU
to the VM. The total number of timer
interrupts being delivered depends on the following factors:
· VMs
running symmetric multiprocessing (SMP), hardware abstraction layers
(HALs)/kernels require more timer interrupts than those running Uniprocessor
HALs/Kernels.
· How
many virtual CPUs (vCPUs) the VM has.
Delivering many virtual timer interrupts can negatively
impact on the performance of the VM and can also increase host CPU consumption. This can be mitigated however, by reducing
the number of vCPUs which reduces the timer interrupts and also the amount of
co-scheduling overhead (check CPU Ready
Time).
Then there's the Memory management of Idle VMs. Each powered on VM incurs Memory
Overhead. The Memory Overhead includes space reserved
for the VM frame buffer and various virtualization data structures, such as
Shadow Page Tables (using Software Virtualization) or Nested Page Tables (using
Hardware Virtualization). This also depends
on the number of vCPUs and the configured memory granted to the VM.
We’ll have a look at a few more reasons to care on Wednesday, in the meantime why not complete our Capacity Management Maturity Survey and find out where you fall on the maturity scale. http://www.metron-athene.com/_capacity-management-maturity-survey/survey.asp
Jamie
Baker
Principal
Consultant