In this example, if the applications supporting the business service were running on physical machines, we would have concluded, based on the earlier scenario, that the database server was the root cause of the performance problem. However, the applications are in fact running in a virtual infrastructure, i.e., inside VMs. In this example, suppose the Oracle database server is running on the same physical server as a Citrix application and a media server (see Figure 2). A sudden increase in access to the media server can cause disk access on the physical server to increase to the point that disk access becomes a bottleneck.

Figure 2: Root-cause diagnosis in a virtual infrastructure is even harder than in a physical infrastructure.  Oracle, Citrix, and Media Server applications are hosted on VMs residing on the same physical server. A sudden surge in requests to the media server causes excessive disk reads on the physical server, thereby slowing down the performance of the Oracle database server.

At this stage, queries handled by the database server start to take longer and longer. Thus the database slowdown in Figure 1 may actually be caused by a sudden increase in workload to the media server in Figure 2. In this case, the root cause of the problem is a disk bottleneck on the physical server caused by an increase in workload for the media server application.

From this example, it should be clear that root-cause diagnosis technologies for virtual environments need to go beyond how they operate in a physical world. For true root-cause diagnosis, VMs running on each physical server must be auto-discovered. Applications running inside each of the VMs need to be detected and the monitoring system should automatically determine which applications coexist on the same physical server. This information is then used to determine where the root cause of a problem lies.

The extent of the automation determines the cost savings that the monitoring solution offers. Reduced downtime directly contributes to a business's bottom line. Further, by pinpointing the root cause of a problem, a monitoring solution can save endless hours of the finger pointing that goes on in most IT organizations. This results in cost savings from enhanced operational efficiency and reduces the man hours spent in routine fire-fighting.

7. Scale as the infrastructure monitored grows - As virtualization penetrates the enterprise, a large deployment will have hundreds of physical servers and thousands of VMs that require monitoring. In fact, as virtualization for desktops becomes popular, the ratio of VMs to physical servers could be as high as 30:1. The monitoring solution must be able to scale to handle such large infrastructures.

8. Support for virtualized desktop environments - Virtual Desktop Infrastructure (VDI) is being viewed as a viable alternative to Citrix- and terminal server-based remote access technologies. For situations where each user requires his/her own desktop as opposed to shared access to an operating system (e.g., for software development or to run a legacy application), VDI is being viewed as the technology of choice for remote access.

Virtual desktop environments have different characteristics than environments where VMs are used to host server applications such as databases and web servers (see Table 1). VDI environments also have an ecosystem of new application technologies, such as the connection brokers, terminal access controllers, etc. A Virtualization 2.0 Ready monitoring solution should be capable of handling the diverse monitoring requirements of virtual server and virtual desktop environments.

Virtualized Application Server Environments	Virtual Desktop Environments
Few VMs (<10) per physical server	30-40 VMs per physical server
VMs are mostly powered on all the time	VMs are powered on/off dynamically
Monitoring is mostly from the VM perspective - which VMs are on, what resources are they using	Monitoring is needed from the user perspective (who is logged in, what resources are they using)
In-depth application monitoring is required (Citrix, Oracle, etc.)	In-depth monitoring of the applications on the desktop is not required

Table 1: Differences exist in monitoring requirements between virtualized application server environments and virtual desktop environments. A Virtualization 2.0 Ready monitoring solution should be able to handle both environments.

9. Offer personalized views for the various stakeholders in an organization to enable collaborative management - Different stakeholders responsible for supporting a business service may need different views of the monitored infrastructure. Virtualization administrators, application experts, database admins, infrastructure architects, help desk personnel, and capacity planners may require different views of the infrastructure in keeping with their roles and responsibilities. The monitoring system must be flexible, providing each stakeholder with views that are aligned with their roles in the organization.

Organizational Process Challenges in Virtualization 2.0
While the previous discussion focused on the monitoring requirements for Virtualization 2.0, it is equally important to understand that Virtualization 2.0 also affects the core of most organizations' operational processes.

Most organizations handle VM provisioning in much the same manner as they do for physical server procurement. Business units and application owners specify the sizing of the virtual machines they need, and the appropriate VMs are provisioned by the virtualization group that handles the physical servers on which the VMs are set up. However, the virtualization group usually does not have any information or visibility into what applications are being hosted inside the VMs. When the physical servers are overprovisioned and fewer VMs are executed in parallel, this siloed approach, wherein the virtualization group and the application teams do not interoperate, is sufficient.

But with Virtualization 2.0, organizations seek better return on investment for virtualization technologies and deploy more complex applications inside virtual environments. Now it is no longer sufficient for the virtualization group to remain oblivious to the resource requirements of the application groups and their VMs. For instance, two memory-intensive applications hosted on the same physical server may contend for the same resources, thereby affecting each other's performance.

Of course, by strictly partitioning the resource usage of each of the VMs, the virtualization group can offer performance guarantees. But this has two key disadvantages. First, strict partitioning reduces the possibility of resource sharing across VMs, thereby limiting the consolidation benefits that virtualization offers. Second, due to limitations in the virtualization technologies, not all resources can be completely isolated across virtual machines; e.g., disk I/O. Hence, Virtualization 2.0 requires that virtualization groups of organizations play a more active role in how VMs are provisioned, including understanding which applications are to be hosted in each VM, what assumptions have been made regarding their workloads and resource requirements, and how the workload of different applications varies over time and with load. All of these details are essential for effective load balancing and optimizing resource usage in a virtual infrastructure.

For example, by hosting a memory-intensive application and a CPU-intensive application on the same physical server, the virtualization group can make best use of the available resources rather than by hosting all CPU-intensive applications on the same physical server.

Yet another problem that virtualization administrators have to contend with under Virtualization 2.0 is finger-pointing and problem diagnosis (see Figure 3). A single business service often spans multiple application and network tiers, so when a problem occurs, it is unclear what caused the problem; i.e., is it the network? The application? The database? The server? In a virtualized infrastructure, there are additional possibilities for where the problem could lie: In a VM? In the physical server? In the hardware? In the virtual network interface? In the SAN?

Figure 3: Monitoring an IT infrastructure as silos does not suffice because finger-pointing across silo administrators takes endless hours, resulting in high downtime for the business service.

Since most administrators already have silo tools for monitoring and management, there is no common dashboard from where the entire infrastructure can be monitored and diagnosed. Virtualization administrators will need to get accustomed to working in a multi-silo organization where finger-pointing is common. Monitoring and management solutions that provide deep visibility into every layer of every tier of the infrastructure and serve as a common dashboard for all the different administrators in an organization can go a long way toward ensuring that Virtualization 2.0 environments operate properly.

Conclusion
Virtualization 2.0 identifies fundamental changes that are needed in terms of how virtualized environments can be monitored most effectively and efficiently. This article outlined the key management and organizational challenges that must be overcome as the use of virtualization continues to increase in production enterprise environments.

Resources
Websites

• www.virtualization.info
• www.vmblog.com
• www.vmware-land.com

Articles

• Monitoring Virtual Infrastructure: Problem's Lack of Knowledge, Not Tools CIO Magazine Virtualization Advisor, May 15, 2008
• Digital Goggles Blog on Virtualization Management July 19, 2008