Published: November 12, 2007   |   Updated: February 25, 2008

After determining the list of applications that the virtual environment will support, the resources required to support those applications needs to be determined. In step 3, the technical requirements for each application that will be virtualized will be collected; this information will be used in subsequent steps to design the host infrastructure.

In the case of existing production applications, determining the resource requirements can be an objective process. However, when a new application is being considered, more subjective approaches may be all that are available. Subjective information sources can come from experience with similar technologies or literature. Objective information sources can include:

• Real-world performance data (based on monitoring existing applications and workloads).
• Specifications and requirements from application and operating system vendors.
• Results from application benchmark testing.
• Details that application developers and systems integrators provide.
• Load-testing based on expected use patterns and metrics.

IT should plan to support the peak load of each application VM to ensure that the host system can handle the full load of all of the applications it hosts. For existing applications, systems administrators should collect performance information from production environments.

This step assumes that an application represents the entire physical server that hosts the application. When collecting performance information then, the counters being collected are for the entire server.

It is further assumed that the entire physical server is to be virtualized, not just the application itself. This approach maps applications to guests on a 1:1 basis. The opportunity exists to go further and combine one or more applications from different servers into a single guest. However, this topic is beyond the scope of this guide.

The tasks in this step involve examining the various hardware resource requirements for each application and operating system that the virtual environment will support. These details are used to determine the size of the virtualization infrastructure environment. The table developed in step 2 will help track the information generated, as shown in Table 4.

Table 4. Tracking Resource Requirements

Note   To provide safeguards against underestimating resource requirements, add a “buffer” amount when determining specific host requirements. You can do this by adding additional capacity for each application or by using a percentage or constant adjustment for all applications.

Task 1: CPU

Over-committing CPU resources can adversely affect all the workloads on the same host server, causing significant performance issues for a larger number of users. Because CPU resource use patterns can vary significantly, no single metric or unit can quantify total resource requirements. One approach, however, is to collect CPU requirement specifications for particular applications and workloads. Table 5 provides the Windows® Performance Monitor statistic to collect over time.

Table 5. Performance Monitor Statistics

Note   Similar performance counters are available for other operating systems.

CPU calls are transmitted directly from VMs to the underlying host computer’s physical CPU. Therefore, a good guideline is to specify the same CPU architecture and speed that would be used for the same applications running on a physical computer.

Document the CPU that the application is running on, and express the CPU demand as a percentage.

Task 2: Memory

Applications that are allotted too little memory will experience frequent disk page faults, resulting in decreased performance and additional disk resource use. In contrast, allocating too much physical memory leaves physical hardware resources unused, leading to lower overall host server utilization.

Collect memory use information when the system is running at peak load to ensure that the appropriate amount of memory is allotted. Table 6 provides the Windows Performance Monitor statistics that should be collected.

Table 6. Performance Monitor Statistics for Required Memory

For each machine being virtualized add approximately 24 megabytes of memory to account for overhead needed by the virtualization host.

Task 3: Disk

This task involves measuring disk storage and performance requirements.

Disk Capacity

Every VM requires disk space to support multiple file and data types. Common types of storage requirements include:

• Operating system storage, including binaries, the paging file, and other required disk resources.
• Application-related storage space.
• User data storage.
• Databases and other required files.

Predicting disk space use is similar for physical and virtual workloads. For existing systems, take the total disk space in use and add a factor for future growth Record in the spreadsheet the total amount of disk storage capacity required for each application.

Disk Performance

To determine the actual disk performance, measure and record the physical I/O that occurs over a period of time, then calculate the Input Outputs per second (IOps)—that is, the total number of I/O operations that occur per second, and plot this over the time period to determine requirements at peak usage.

The IOps calculations for a RAID 0+1 configuration is (Reads Required + (Writes Required *2)) / Max Drive IOps. The IOps calculations for RAID 5 configuration is (Reads Required + (Writes Required *4)) / Max Drive IOps.

Given a specific configuration such as a RAID 5 array of five drives (with each drive capable of approximately 135 IOps), the IOps capacity of an existing configuration can also be calculated.

By using Windows Performance Monitor, what the current system is actually using in terms of IOps can be measured. However, that number does not indicate whether the system has a bottleneck in the disk subsystem. To see whether the system is disk-bound, look at the queue length of the physical disk. The queue length should be zero on a well-performing system.

Disk Performance Counters

Table 7 provides the Windows Performance Monitor statistics that should be collected.

Table 7. Performance Monitor Statistics for Disk Performance

Note   Similar performance counters are available for other operating systems.

Total the Physical Disk counters from the table above to calculate the IO usage for each system. Record the values in the table.

Task 4: Network

Most workloads require access to production networks to ensure communication with other applications and services and to communicate with users. Network requirements include elements such as throughput—that is, the total amount of traffic that passes a given point on a network connection per unit of time.

Other network requirements include the presence of multiple network connections. Workloads might require access to several different networks that must remain secure. Examples include connections for:

• Public network access.
• Networks for performing backups and other maintenance tasks.
• Dedicated remote-management connections.
• Network adapter teaming for performance and failover.
• Connections to the physical host server.
• Connections to network-based storage arrays.

Add the number of required network connections to the spreadsheet that was created earlier.

Network Performance Counters

Table 8 provides the Windows Performance Monitor statistics that should be collected over time and graphed to record peak usage.

Table 8. Performance Monitor Statistics for Network Performance

Note   Similar performance counters are available for other operating systems.

Add the values for each application, and then add the information to the spreadsheet that was created earlier.

Task 5: Backup

Considering backup requirements for applications helps inform storage, network, and other requirements in subsequent steps in this guide. Some types of workloads might not require backups. For example, a Web server that presents static data might simply be rebuilt in case of a failure. Most workloads, however, contain important configuration settings, operating system settings, and user data that must be protected in the case of a VM failure.

• If this application requires backup, record it in the table.

Task 6: Availability

The requirement for high availability in applications has significant implications for host storage, network, and availability infrastructure. However, the most important question is: Does the application require high availability through fault tolerance?

For each application that requires high availability, determine the necessary method. Options include:

• Network load balancing. Primarily for stateless applications such as Web servers that serve static content or that store session state in a shared location.
• Cluster-aware applications. For applications that are Microsoft Cluster Service (MSCS) aware, such as Microsoft Exchange Server and Microsoft SQL Server™.
• Host clustering. When network load balancing is not appropriate and the application is not cluster aware, some risk mitigation can be achieved by running the VM on a host system that is part of an MSCS cluster. Because the application is not cluster aware, there is no assurance that the application will recover gracefully from a failure. However, this practice offers a best-odds approach to minimizing downtime when no other fault tolerant options exist.

Task 7: Coexistence and Physical Isolation

From a technical standpoint, it is possible to support a wide variety of different workloads on the same physical computer. However, business or technical characteristics may prevent more than one system from running on the same server. One example is the need for VMs to exist in different physical locations. When supporting hubs and satellite offices, specific sites may require certain VMs.

Security and regulatory compliance requirements can also drive the need to keep certain workloads separate. If specific applications, databases, and services must remain segregated, note them (along with the reasons, such as security, regulatory compliance, or business policies) in the table above. This data will be used to determine the acceptable placement of guest VMs in the infrastructure.

Validating with the Business

The primary considerations in step 3 are the technical resource requirements for each application. Although IT departments are often able to measure factors such as CPU, memory, disk, and network use, other details will require business input. Specifically, work with business decision makers to ensure agreement on the specific details of the following considerations:

• Would any regulatory requirements or political issues prevent combining specific applications on the same servers? In addition to technical requirements for physical isolation and coexistence, business or political issues can prevent the same server hosting specific applications.
• Are there any legal concerns about the geographical location of an application? Legal requirements and international regulations can prevent certain applications from residing in specific geographic locations.
• Confirm the availability and backup requirements for each of the applications.
• What are the expected growth patterns for each of the applications, over the next two to three years? This will enable a sizing of the virtualization environment to accommodate that growth.

Decision Summary

After completing this step, the total resource requirements for all the applications that the organization’s virtual infrastructure will host have been identified. To obtain rough estimates of the total requirements, add each row of each resource requirement. Doing so provides an estimate of the total amount of memory and other resources required in future steps.