Today is day two of VMworlds and VMware’s Keynote speech was atop the list of things to see. A majority of the info has already been rehashed all over blogs so I wont go into details, but I did want to touch on a major point that was mentioned. Paul Martiz, President and CEO of VMware, announced that for the first time ever, the number of virtual machines has surpassed the number of physical machines.
This is huge news in the field is systems administration and engineering. This means the tipping point has been reached, where virtualization is no longer just a cutting edge technology, but the norm. Admins and engineers will now be required to know the ins and outs of virtualization and shift from the standard practices of physical environments. The VCP will become, and is becoming, a more common certification, and one they may even be required. The impact of this though, is that admins and engineers will require more training and knowledge than ever before, because while physical servers just require systems to be racked and OSes installed, virtual environemnts require knowledge and planning of storage, networking and scalability and capacity planning.
All and all, this is a good thing and I for one and glad to see this technology that we all enjoy thriving so well. I hope to continue to see if and maybe even by 2012, see the numbers be 75%/25% for virtual to physical systems.
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.
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.
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?