CPU Ready: Over Built VM or Over Utilized Host?

When talk performance with any virtualized server environment, CPU Ready is a common key indicator of how well your VM is performing. However, its not always a cut and dry explination as to why your CPU Ready times are high.

To start, for those that aren’t aware, CPU Ready is:

The amount of time a virtual machine waits in the queue in a ready-to-run state before it can be scheduled on a CPU.

This means that a VM is ready to process something, however, it has to wait because the CPU resources it requires are not available on the physical host.

Before we examine causes of high CPU Ready, lets try to look at what are acceptable values for CPU Ready time. Unfortunately, there is no hard set value to say ‘Yep, your CPU Ready has crossed the ‘its bad’ threshold.’ General rule of thumb is that your CPU Ready time not be higher than 200ms if being checked in the vCenter performance charts, or 5% if being checked using the esxtop command. Again, this isn’t a hard set value. Your VMs role may require less CPU Ready time for more critical functions, or may be more lenient to longer CPU Ready times as well. It all depends on your environment, and its up to you as an admin to determine what works in your individual environment.

Physical Requirements vs. Virtual Provisioning (Part 2)

After a delay, I bring you Part 2 in the discussion of Physical vs Virtual Provisioning. In the opening post of this series, I gave a few recent examples of VM request that had graced my screen and shocked my brain. In today’s post, I want to examine some of the reasons why the requirements differ from a physical to a virtual machine.

The main difference between a physical machine and a virtual machine is the lack of hardware. By lack of hardware, I don’t mean there is no hardware at all; we all know there has to be hardware somewhere. By no hardware, I mean the machine and OS itself aren’t aware they are virtual and don’t run on its own physical server. I don’t want to get too caught up on that discussion. The point to my comment is that the lack of the physical hardware means a lack of physical hardware drivers. We all know how much of a pain, and resource hog, drivers can be. No one really knows how much of your CPU cycles and Memory I/O activities are the work of drivers translating actions between the physical and application level. 

Physical Requirements vs. Virtual Provisioning (Part 1)

Part of my day-to-day job is to deploy new virtual machines for the client. These VMs are deployed with specifications given to us by the client. Lately, I’ve noticed an increasing trend of over-powered virtual machines being requested, and it seems the mentality for these request is that the application states the physical requirements, so that is what is being requested of us. This increasing trend kicked off a debate between myself and a few of my co-workers on the topic of Virtual Provisioning versus the Physical Requirements.

First, let me start of by stating that my client is very new to virtualization. We are only utilizing about 95 Virtual Servers, 80 Virtual Desktops, and 13 ESX host, mostly in a non production environment. We are mid deployment of our largest, full production data center. The client is definitely eager to jump into virtualization, but still hasn’t fully grasp the concepts being virtualization.

My latest VM provisioning request was for a Windows Server 2008 x64 Enterprise Edition machine. The VM will be used as a Sql Server Reporting Services (SSRS) machine in a test/development environment. The VM will be used to assess the benefit and abilities of SSRS, and determine if it’s a viable solution to deploy into production. Given the use of this VM, I figured the required specs would run along the lines of 1 vCPU and 1-2GB of Memory, right?