Information Technology Reference
In-Depth Information
successful sales pitches is being able to take all those lackluster physical boxes that are not busy
and convert them to VMs. Once they are converted, virtual infrastructure managers tend to
think of these VMs as simple, lackluster, and low-utilization servers with nothing to worry over
or monitor. The truth, though, is quite the opposite.
When the server was physical, it had an entire box to itself. Now it must share its resources
with many other workloads. In aggregate, they represent quite a load, and if some or many of
them become somewhat busy, they contend with each other for the i nite capabilities of the ESXi
host on which they run. Of course, they don't know they are contending for resources because
the VMkernel tries to make sure they get the resources they need. Virtual CPUs need to be
scheduled, and ESXi does a remarkable job given that there are more VMs than physical proces-
sors most of the time. Still, the hypervisor can do only so much with the resources it has, and
invariably there comes a time when the applications running in a VM need more CPU time than
the host can give.
When this happens, it's usually the application owner who notices i rst and raises the alarm
with the system administrators. Now the vSphere administrators have the task of determining
why this VM is underperforming. Fortunately, vCenter Server provides a number of tools that
make monitoring and analysis easier. These are the tools you've already seen: alarms, perfor-
mance charts, vC Ops, and resxtop.
Let's begin with a hypothetical scenario. A help desk ticket has been submitted indicating
that an application owner isn't getting the expected level of performance on a particular server,
which in this case is a VM. As the vSphere administrator, you need to i rst delve deeper into the
problem and ask as many questions as necessary to discover what the application owner needs
to be satisi ed with performance. Some performance issues are subjective, meaning some users
might complain about the slowness of their applications, but they have no objective benchmark
for such a claim. Other times, this is rel ected in a specii c benchmark, such as the number of
transactions by a database server or throughput for a web server. In this case, our issue revolves
around benchmarking CPU usage, so our application is CPU intensive when it does its job.
Assessments, Expectations, and Adjustments
If an assessment was done prior to virtualizing a server, there might be hard numbers to look at to
give some details as to what was expected with regard to minimum performance or a service-level
agreement (SLA). If not, the vSphere administrator needs to work with the application's owner to
make more CPU resources available to the VM when needed.
vCenter Server's charts, which you have explored in great detail, are the best way to analyze
usage, both short and long term. In this case, let's assume the help desk ticket describes a slow-
ness issue in the last hour. As you've already seen, you can easily create a custom performance
chart to show CPU usage over the last hour for a particular VM or ESXi host.
Perform the following steps to create a CPU chart that shows data for a VM from the last
hour:
1.
Connect to a vCenter Server instance with the vSphere Web Client.
2.
Navigate to the Hosts And Clusters or VMs And Templates view.
3.
In the Navigator, select a virtual machine.
