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.
Imagine if you have a large number of idle VM's, as the report below picked up for a client:
We’ll have a look at a few more reasons to care on Friday.
Jamie Baker
Principal Consultant
No comments:
Post a Comment