Combine vCenter logging and performance metrics to troubleshoot virtual systems. Hypervisors might add complexity, but they also offer new levels of insight.
If an issue comes up in a VMware environment, administrators can use vCenter monitoring capabilities to gather data that's more detailed than the data available in a traditional OS.
Often, IT administrators and managers think applications crash because of VMware or a particular issue that supposedly never occurred before virtualization. However, VMware's vCenter and its related virtualization products constitute revolutionary changes to the data center.
Hardware is something people can see, and the ability to touch it is reassuring. While many organizations have embraced virtualization, some people are still skeptical. If issues occur, the virtual admin can put those fears to rest using vCenter monitoring and logging capabilities.
VMware vCenter functions at a different level than traditional monitoring tools. VCenter monitoring data comes from a layer below the guest OS. VCenter and vCenter-based monitoring tools, including third-party tools that pull this data, see below the OS layer directly at the virtual hardware level.
Traditional Windows-based monitoring tools can't reach that level. Windows gets its data from software drivers and APIs, but this data rests on an interpretation of what Windows is seeing. If everyone is looking at Windows tools rather than vCenter tools, serious confusion can result because different people are seeing different data.
A clear example of this is memory usage within Windows. An application with 10 GB of memory allocated will typically display this in Windows tools such as Task Manager and Resource Manager. Allocated memory, however, is different from memory in use, and without using the Perfmon plug-in from VMware Tools, it's almost impossible to determine this from inside Windows.
VCenter monitoring makes it easy because the memory the VM is using isn't real -- it's software-based. VCenter can then differentiate between allocated and in-use memory. Though 10 GB of RAM might be allocated, only a few GB might be in use. If the application owner only sees the Windows value, it can look like the VM is resource-constrained when, in reality, vCenter can show that isn't the case.
Once workloads are virtualized, aspects for the guests often change, but it's typically an improvement. The challenge shifts from a lack of resources to resource allocation.
Enhance troubleshooting with vCenter monitoring
The key to virtualization troubleshooting is to ensure workloads aren't waiting for resources. When servers are only dedicated to one application per hardware platform, there aren't many options beyond an upgrade.
In a virtualized environment, the rules are different. It becomes possible to look at things like queue depth in storage to find the source of an I/O delay. Examine CPU Ready Time to see how long VMs are waiting for CPU access and if they are CPU-constrained. Compare memory allocation to in-use values to see what might be swapping or caching RAM.
Performance metrics can help provide answers to questions about the logs and other events.
All of these vCenter monitoring settings enable deep inspection and help coordinate adjustments to resource allocation through shares and resource pools. After making these adjustments, it's critical to stay on top of performance metrics. Changes to one workload might have a negative effect on another; it's a shared environment, after all.
Performance metrics can help provide answers to questions about the logs and other events. For example, was vMotion occurring at the same time a VM was having issues? VCenter logging data can explain what events were occurring at the time, but the performance data in vCenter will show if an event truly caused an issue. Use both to get a complete picture of what's going on.
Don't completely leave out OS logs and events. They can help fill any gaps, but be careful about the hardware and performance aspects because the OS won't have deep insight on those values.
The hypervisor adds another level of complexity to the application troubleshooting process. That additional layer, however, creates a window into the application and OS stack that didn't exist with traditional hardware. The challenge is piecing together the data at that level and making the proper adjustments.
A mistake can upset the entire virtualized environment, so a small adjustment is always a good starting point rather than implementing a large-scale change.
