Requirements for "Virtualization 2.0 Ready" Monitoring Solutions
The emphasis on monitoring and management in Virtualization 2.0 is shifting from virtual machine (VM) management to business service management; i.e., knowing how a business service is performing and which domains (network, server, VM, applications) are working properly and which are not. Hence, it's no longer sufficient to just monitor the uptime or resource usage levels of virtual machines and physical servers and believe that the entire IT infrastructure is working well.

The key requirements for a Virtualization 2.0 Ready monitoring and management solution are provided below:

1. Provide a single view of virtual and physical infrastructures - Even though virtual infrastructures are being used for many mission-critical applications, most enterprises are moving to virtualization only in a phased manner. For example, I/O-intensive applications are still being hosted on non-virtual servers. Therefore, a business service may involve some applications that reside on physical machines and others that run on virtual machines. To provide an integrated view of the target infrastructure, the monitoring and management system needs to be able to manage infrastructures with a set of virtual and physical machines equally well, providing a single integrated interface across these different technologies.

2. Support multiple virtualization technologies - Administrators now have a choice of virtualization technologies based on their business needs and preferences. VMware ESX, Citrix Xen, Microsoft Hyper-V, as well as different Unix options (Solaris Containers, AIX LPARs) all offer robust solutions for virtualization. Most large infrastructures will include a mix of these virtualization technologies, and it's important to have a single unified dashboard from where these different virtualization technologies can be monitored.

3. Track physical resource availability, configuration and usage by VMs - As deployment of virtual infrastructures proliferates, it is essential that administrators have a comprehensive view of the virtual infrastructure. While monitors designed for conventional physical machines can be installed and used on individual VMs, they have no specialized capabilities for virtualized environments. Knowing such things as how the hypervisor is performing, which VMs are powered on and what resources they are using, if the physical server has sufficient resources to handle its workload, whether the VMs are configured with sufficient resources, etc., are critical requirements that only a monitoring solution that is specialized for virtual infrastructures can deliver.

Many virtualization platforms support high availability and live migration configurations to provide reliability and failover for mission-critical applications. Administrators need to know whether these capabilities are working properly or whether any configurations need to be tuned (e.g., are migrations happening too often? Why did a migration suddenly take place?).

4. Provide an "inside view" of virtual machines with clear problem identification - While most virtualization administrators understand the importance of tracking the resource usage levels (CPU, memory, disk, network) of each of the VMs on a physical server, very few can monitor what is going on within each virtual machine. This is because most Virtualization 1.0 monitoring solutions focused on capacity planning and provisioning. For capacity planning and provisioning, it is important to track the portion of a physical server's resources that each VM is taking up.

This view, which provides insight into how a physical server's resources are used across all its VMs, is the "outside view" of a VM. While the outside view helps identify a resource-hungry VM, it falls short of providing additional information that is critical for problem diagnosis and further optimization. For instance, why is a specific VM taking up excessive resources? Is it because of a heavy workload? Or is it due to a malfunctioning application (e.g., a runaway job or a memory leak in one of the applications running in the VM)? To provide this information, an "inside" view of each VM is necessary. This view tracks such dynamics as end-user activity, resource allocation for each application, and the application mix running inside the VM guest operating system.

As virtualization goes mainstream, it will no longer be sufficient to just plan and provision virtual infrastructures correctly. Production environments are dynamic, and when problems occur it's important to determine what is causing the problem. Is the physical server running out of capacity? Is it a VM not having sufficient resources because it was not correctly provisioned? Is it a malfunctioning application inside the VM? The answer to these questions will determine who is responsible for fixing a problem - is it the VM administrator, or is it the application administrator/expert? Only a monitoring solution capable of presenting both the "outside" and "inside" views can provide this richness of information.

5. Automatically establish performance baselines and norms - Often, the emphasis of monitoring is just problem diagnosis. When there is a problem, administrators want to know what is wrong. While problem detection is easy (if your monitoring system does not alert you, your users will), isolating the problem and determining what the true root-cause of a problem is can be a challenge. Establishing performance baselines and norms was important in the non-virtual world. This is even more important in a virtualized world, since the number of "moving parts" is much higher (hypervisor, VMs, applications, migration, etc.).

Understanding what has changed and when is critical to quickly zooming in on the root cause of a problem. The ability to establish these norms automatically is important in many ways. Administrators do not always know what is "normal" in their environment. The norm also varies from one server to another based on its sizing. Experts who understand what norms need to be adopted are few and not readily available. Even for such experts, setting norms for each and every server can be an arduous task. Hence, it's important to have the right automation built into the monitoring system to automatically determine what the performance baselines are for the infrastructure.

This capability is also key to being able to monitor your infrastructure proactively. The monitoring solution should be able to compare current performance with respect to the baseline and be able to generate alerts well before a failure happens. This provides administrators with precious advanced notice that can help them avert potentially serious failures in business service performance.

6. Perform automatic correlation for true root-cause diagnosis - While auto-baselining can provide proactive alerts, analyzing these alerts and determining the precise root cause of a problem is a huge challenge. Effective root-cause diagnosis is critical to reducing the downtime of business services and enhancing operational efficiency so expert staff spend less time fire fighting.

Root-cause diagnosis in a physical infrastructure is a huge challenge. The addition of virtualization just makes the problem harder. To understand why, consider a business service supported by a typical configuration of multiple application tiers (see Figure 1). In this example, the user accesses the service through a firewall. User requests are forwarded by the web server to a middleware application server. The application server performs the business logic, accessing a back-end database to get the data for analysis. If the database server were to slow down suddenly by 50%, since the application server depends on the database for its functioning, the application server will become slower than normal. This in turn will result in the web server appearing to be slow and the end-user response will be poor.

In this case, a problem in one application tier affected all the other tiers that depend on it. Diagnosing a problem in a multi-tier architecture requires an understanding of the inter-dependencies that exist among applications in the underlying infrastructure, and then using these inter-dependencies to determine where the root cause of a problem lies and what the effects are.

Figure 1: When diagnosing problems in a multi-tier infrastructure, a single business service often involves multiple tiers of inter-dependent applications. Hence, a problem in one tier can affect all the other tiers. Root-cause diagnosis must account for these inter-dependencies.