IPD - Windows Server Virtualization

Infrastructure Planning
and Design
Windows Server Virtualization
Version 1.0
Published: November 2007

Updated: February 2008
For the latest information, please see microsoft.com/technet/SolutionAccelerators
FPO
Copyright © 2008 Microsoft Corporation. This documentation is licensed to you under the
Creative Commons Attribution License. To view a copy of this license, visit
http://creativecommons.org/licenses/by/3.0/us/ or send a letter to Creative Commons, 543
Howard Street, 5th Floor, San Francisco, California, 94105, USA. When using this documentation,
provide the following attribution: Infrastructure Planning and Design is provided with permission
from Microsoft Corporation.
This documentation is provided to you for informational purposes only, and is provided to you
entirely "AS IS". Your use of the documentation cannot be understood as substituting for
customized service and information that might be developed by Microsoft Corporation for a
particular user based upon that user’s particular environment. To the extent permitted by law,
MICROSOFT MAKES NO WARRANTY OF ANY KIND, DISCLAIMS ALL EXPRESS, IMPLIED AND
STATUTORY WARRANTIES, AND ASSUMES NO LIABILITY TO YOU FOR ANY DAMAGES OF ANY
TYPE IN CONNECTION WITH THESE MATERIALS OR ANY INTELLECTUAL PROPERTY IN THEM.
Microsoft may have patents, patent applications, trademarks, or other intellectual property rights
covering subject matter within this documentation. Except as provided in a separate agreement
from Microsoft, your use of this document does not give you any license to these patents,
trademarks or other intellectual property.
Information in this document, including URL and other Internet Web site references, is subject to
change without notice. Unless otherwise noted, the example companies, organizations, products,
domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious.
Microsoft, Hyper-V, Outlook, Windows, and Windows Server are either registered trademarks or
trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.
You have no obligation to give Microsoft any suggestions, comments or other feedback
("Feedback") relating to the documentation. However, if you do provide any Feedback to Microsoft
then you provide to Microsoft, without charge, the right to use, share and commercialize your
Feedback in any way and for any purpose. You also give to third parties, without charge, any
patent rights needed for their products, technologies and services to use or interface with any
specific parts of a Microsoft software or service that includes the Feedback. You will not give
Feedback that is subject to a license that requires Microsoft to license its software or
documentation to third parties because we include your Feedback in them.
Solution Accelerators microsoft.com/technet/SolutionAccelerators

Contents
The Planning and Design Series Approach..........1
Introduction ................................................. .....4
Windows Server Virtualization in Microsoft
Infrastructure Optimization...............................5
Virtualization Design Process.............................7
Step 1: Determine the Virtualization Scope........9
Step 2: Create the List of Applications..............12
Step 3: Determine Resource Requirements.......15
Step 4: Select the Backup Approach for Each
Application.............................................. .........21
Step 5: Applying Fault Tolerance .....................23
Step 6: Summarize and Analyze the Application
Requirements................................................ ...26
Step 7: Select a Form Factor for the Hosts........28
Step 8: Determine Server Placement................30
Step 9: Map Guests to Hosts................ .............33
Step 10: Determine the Host Backup Approach. 35
Step 11: Design Fault Tolerance.......................37
Step 12: Design the Storage Infrastructure .....39
Step 13: Design the Network Infrastructure.....41
Step 14: Validate the Overall Approach............44
Conclusion........................... ............................45
Appendix..................................................... .....46
Acknowledgments............................... .............48

The Planning and Design Series
Approach
This guide is one in a series of planning and design guides that clarify and streamline the
planning and design process for Microsoft® infrastructure technologies. Each guide in the
series addresses a unique infrastructure technology or scenario. These guides include
the following topics:
• Defining the technical decision flow (flow chart) through the planning process.
• Describing the decisions to be made and the commonly available options to consider
in making the decisions.
• Relating the decisions and options for the business in terms of cost, complexity, and
other characteristics.
• Framing the decision in terms of additional questions for the business to ensure a
comprehensive understanding of the appropriate business landscape.
The guides in this series are intended to complement and augment Microsoft product
documentation.
Document Approach
This guide is designed to provide a consistent structure for addressing the decisions and
activities most critical to the successful implementation of the infrastructure for Windows
Server® 2008 Hyper-V™ technology and Microsoft Virtual Server 2005 R2 SP1. Each
decision or activity is subdivided into four elements:
• Background on the decision or activity, including general considerations.
• Typical options or tasks to perform for the activity.
• A reference section that evaluates items such as cost and complexity for the options
or tasks identified.
• Questions for the business that might significantly affect the decisions to be made.
Table 1 lists the full range of characteristics discussed in the option-evaluation sections
later in this guide. Only the characteristics relevant to a particular option or task are
included in each section.

2 Infrastructure Planning and Design
Table 1. Characteristics
Characteristic Description
Complexity This characteristic relates the effect a choice will have on
overall infrastructure complexity.
Cost This value shows the relative cost associated with a particular
option. This takes into account initial and repetitive costs
associated with the decision.
Fault tolerance The fault tolerance characteristic indicates the effect the option
will have on the ability of the infrastructure to sustain operation
during system failures.
Performance Performance is rated based on the effect the option will have
on the performance for the technology featured in the guide.
This does not necessarily reflect the impact on other
technologies within the infrastructure.
Scalability This characteristic depicts the effect the option will have on the
ability of the solution to be augmented to achieve higher
sustained performance within the infrastructure.
Security This value reflects whether the option will have a positive or
negative impact on overall infrastructure security.
Each of the design options is compared against the above characteristics and is
subjectively rated in order to provide a relative weighting of the option against the
characteristic. The options are not explicitly rated against each other as there are too
many unknowns about the business drivers to accurately compare them.
The ratings take two forms:
• Cost and Complexity are rated on a scale of High, Medium, or Low.
• The rest of the characteristics are rated on the scale listed in the following table.
Table 2. Additional Characteristics
Symbol Definition
↑ Positive effect on the characteristic.
→ No effect on the characteristic or there is no comparison basis.
↓ Negative effect on the characteristic.
The characteristics are presented either as two-column or three-column tables. The two-
column table is used when the characteristic is applicable to all options or when there are
no options available—for example, when performing a task.
The three-column table is used to present an option, the description, and the effect—in
that order—for the characteristic.
There are times that decisions being made within the business may affect the
infrastructure design. The “Validating with the Business” section is used to provide
additional questions that should be asked of the business leaders. In addition, this
provides a means to have check points within the design process to give the business
leaders a way to provide additional input into the design process.

Windows Server Virtualization 3
Who Should Use This Document

This guide is written for information technology (IT) infrastructure specialists who are
responsible for planning and designing a Windows Server 2008 Hyper-V or Virtual
Server 2005 infrastructure for server virtualization. These specialists include consultants,
internal IT architects, and others who are concerned with design decisions related to
virtualization.
The content in this guide assumes that the reader is familiar with Microsoft virtualization
technology and its potential applications.

Introduction
This guide leads the reader, step by step, through the process of planning the server
virtualization environments. The first six steps in the guide focus on determining
requirements for the guest operating systems, applications, and services; they enumerate
the capacity and performance requirements that will be used in planning host systems.
By addressing information such as resource requirements, backup approaches, and
availability first, the user can determine the size of the load that the virtual applications
will require from the host infrastructure.
Steps 7 through 13 in the guide focus on the planning and design issues that affect the
physical host infrastructure design. Specific guest workload requirements determine the
server form factor, server placement, and the storage and network architecture. Specific
steps and an overview of the entire decision process appear later in this document.

Windows Server Virtualization in

Microsoft Infrastructure Optimization
The Infrastructure Optimization (IO) Model at Microsoft groups IT processes and
technologies across a continuum of organizational maturity (for more information, see
Microsoft.com/io). The model was developed by industry analysts, the Massachusetts
Institute of Technology (MIT) Center for Information Systems Research (CISR), and
Microsoft's own experiences with its enterprise customers. A key goal for Microsoft in
creating the Infrastructure Optimization Model was to develop a simple way to use a
maturity framework that is flexible and can easily be used as the benchmark for technical
capability and business value.
IO is structured around three information technology models: Core Infrastructure
Optimization, Application Platform Optimization, and Business Productivity Infrastructure
Optimization. According to the Core Infrastructure Optimization Model, organizations that
are actively pursuing server consolidation for production workloads with virtualization are
meeting one of the requirements in order to move to the Rationalized level. This guide
will assist in planning and designing the infrastructure for virtualizing server workloads
using Windows Server 2008 Hyper-V and Virtual Server 2005 R2.
Figure 1. Mapping of technology into Core Infrastructure Model
Infrastructure and Business Architecture

Microsoft produces architectural decision-making guidance for IT infrastructure and
business architecture. The architectural principles and decisions presented in the
Infrastructure Planning and Design series are relevant to IT infrastructure architecture.
The business architecture templates from Microsoft are focused on detailed business
capabilities, such as price calculation, payment collection process, and order fulfillment.
Although the IT infrastructure will affect business capabilities, and business architectural
requirements should contribute to infrastructure decisions, the Infrastructure Planning
and Design series does not define or correlate specific individual business architecture
templates. Instead, the Infrastructure Planning and Design guides will present critical
decision points where service management or business process input is required. For
additional information about business architecture tools and models, please contact your
nearest Microsoft representative or watch the video about this topic at
http://channel9.msdn.com/ShowPost.aspx?PostID=179071.

Feedback
Please direct questions and comments about this guide to satfdbk@microsoft.com.

Virtualization Design Process

This guide addresses the most common scenarios, decisions, activities, options, tasks,
and outcomes that organizations encounter when implementing a virtual server
environment. It does not, however, attempt to address every possible scenario. If an
environment is unique, design consultants or specialists should be employed to address
specific needs.
Decisions
The following steps represent the most critical design elements in a successful, well-
planned implementation of Windows Server 2008 Hyper-V or Virtual Server 2005 for
server virtualization:
• Step 1: Determine the virtualization scope.
• Step 2: Create the list of applications.
• Step 3: Determine the resource requirements.
• Step 4: Select the backup approach for each application.
• Step 5: Select the high-availability approach.
• Step 6: Summarize and analyze the application requirements.
• Step 7: Select a form factor for the hosts.
• Step 8: Determine server placement.
• Step 9: Map guests to hosts.
• Step 10: Determine the host backup approach.
• Step 11: Design high availability.
• Step 12: Design the storage infrastructure.
• Step 13: Design the network infrastructure.
• Step 14: Validate the overall approach.
Where an item represents decisions the organization must make, this guide presents a
corresponding list of common response options. Other items in this list represent tasks
the organization must complete; they appear in this guide because they are needed to
complete the infrastructure design.
Decision Flow
Figure 2 shows the flow diagram for the steps, both decisions and tasks, which are
included in this guide.

Figure 2. Decision flow diagram
Information Collection
Organizations must have the following information when designing a server virtualization
infrastructure:
• General business requirements. Before performing step 1, an organization must
have a thorough understanding of its primary business goals for implementing a
server virtualization environment to ensure that the technical decisions can be
matched to business requirements.
• List of server assets. Prior to beginning step 7, an organization should create a list
of the server and network hardware assets present in its environment. This
information is used if an organization is considering the reuse of existing hardware.
Applicable Scenarios
Planning for the server virtualization infrastructure may apply to the following types of
goals and scenarios:
• Server consolidation
• Support for legacy operating systems and applications
• Reducing deployment and provisioning times
• Reducing data center and hardware costs by increasing hardware utilization
• Implementing training labs
Out of Scope
Although the infrastructure planning information in this guide applies to many applications
of virtualization technology, certain details are outside the scope of this document. Such
details include:
• Disaster recovery and business continuity planning.
• Creating development and test environments.
• Increasing workload security through virtualization.
• Operating the virtualized environment.
• Considerations for virtualization hosting providers.

Step 1: Determine the Virtualization

Scope
Before beginning to plan for and design a virtualization infrastructure, an organization
needs to determine which parts of its environment to include in the design. The goal of
this initial step is to define the scope of the virtualization infrastructure. Virtualization can
be deployed across the entire enterprise, or to specific hub locations (a regionalized
approach), or to individual satellite offices (a decentralized approach). This section
examines each of these options.
This step drives decisions related to how organizations implement virtualization. This
information helps determine how the computing environment is intended to run, allows for
mapping requirements to a virtual infrastructure, and defines the mode of operations
following the virtualization implementation. Because details relating to workloads and
other technical decisions vary for each scenario, this guide was designed as a review of
each scenario’s required tasks, decisions, and questions. If an organization is
considering multiple options, it should complete the steps in this guide for each option.
Option 1: Enterprise Deployment

This option involves deployment of virtualization technology to the entire organization,
including corporate data centers.
Benefits
• Delivers standardization across the enterprise and the associated economies of
scale.
• Maximizes the return on investment that can be realized by the virtualization project.
Challenges
• Upfront costs of the virtualization project are all incurred before the benefit is fully
realized.
• High risk, because of the large number of systems that will be affected.
Option 2: Hub Deployment

This option involves deployment of virtualization technology to one or more hub locations.
Hubs are physical locations where there are concentrations of users, computers, and/or
network connectivity. Resources within the hub may be provided to additional satellite
locations.
Benefits
• Provides a pilot environment in which to prove the process and benefits of
virtualization before deployment on a wider scale.
• Can deliver standardization across a region and the associated economies of scale.
• Increases the return on investment that can be achieved by the virtualization project
when compared to a decentralized approach.
Challenges
• Upfront costs of the virtualization project are relatively high.
• Medium risk, because a significant number of systems will be virtualized at one time.
• Disruptive, since numerous changes will be made at the same time.

Option 3: Satellite Deployment

This option involves deployment of virtualization technology to one or more satellite
locations. Satellite locations are smaller than enterprise or hub environments and often
have limited network connectivity to the rest of the environment because of bandwidth
constraints.
Benefits
• Upfront costs of the virtualization project are relatively low.
• Lower risk, because a smaller number of systems will be virtualized at one time.
• Provides a pilot environment in which to prove the process and benefits of
virtualization before deployment on a wider scale.
Challenges
• Potentially creates a non-standard configuration in smaller, remote locations.
• More complex to implement since satellite offices often lack dedicated technical staff
with expertise to optimize systems, which makes support and troubleshooting more
costly.
• Limited return on investment that can be achieved by the virtualization project when
compared to a larger implementation.
When implementing virtualization in hub and/or satellite locations, organizations may
have two primary infrastructure options: They can build a virtual infrastructure within the
hub or satellite office itself, or they can move server-related resources to a centralized
hub or data center location.
Evaluating the Characteristics

The following tables compare the characteristics of the options.
Complexity Justification
Enterprise Many systems to virtualize. H
Hub Fewer systems but limited virtualization skills available onsite. M
Satellite Few systems but often no dedicated staff with virtualization L
expertise.
Cost Justification
Enterprise Large numbers of systems requires the greatest effort. H
Hub Medium number of systems means less effort. M
Satellite Smallest number of systems minimizes the work involved. L

Validating with the Business

When deciding which portion of the infrastructure to virtualize, business stakeholders
should ask questions similar to the following to ensure that they have a complete view of
how the planned infrastructure affects the business:
• What is the primary reason for implementing virtualization? Business goals
should determine which portions of the infrastructure to virtualize—for example,
reducing data center costs by reducing the number of physical servers as well as
consolidating applications and workloads. Another business goal may be to reduce
deployment time for new applications and operating systems. Virtual machine (VM)
deployment requires significantly less time than physical machine deployment.
• What is the expected timeline for moving to virtualization? In many cases,
organizations start with a limited deployment in order to gain expertise with the
technology and to test various configurations.
Decision Summary
Decisions about which part of the infrastructure to virtualize should be based on the
specific needs of the organization. The scope of the virtualization project drives decisions
in future steps related to capacity requirements. Although there is no single “best”
approach to follow, ensure that the entire organization is aligned with and supports the
selected approach before continuing the planning process.
Additional Reading
• Virtual Server 2005 Case Studies at
http://www.microsoft.com/windowsserversystem/virtualserver/evaluation/casestudies/
default.mspx provide information on how various organizations have implemented
virtualization technologies.
• For information on how Microsoft IT has deployed server virtualization technology,
see the Technical Solution Brief, “Server and Data Center Consolidation: Microsoft IT
Enhances Cost Savings, Availability, and Performance,” at
http://www.microsoft.com/technet/itshowcase/content/svrdatactrconsoltsb.mspx.
• Windows Server 2008 Hyper-V library at
http://technet2.microsoft.com/windowsserver2008/en/library/5341cb70-0508-4201-
a6da-dcac1a65fd351033.mspx.
• Windows Server 2008 Hyper-V Resources at
http://www.microsoft.com/virtualization/resources.mspx#documents.

Step 2: Create the List of Applications

Before designing and implementing the infrastructure, determine which applications the
infrastructure needs to support. This information will be used in later steps to determine
resource requirements and, ultimately, to design the physical host infrastructure.
Task 1: Determine Application Compatibility

Although the goal of virtualization technology is to provide virtual environments that can
support a wide variety of operating systems and applications, certain limitations can
prevent some types of workloads from running virtualized. The first step in deciding which
applications to virtualize is to consider the specific technical requirements for the
application or operating system and map that against any constraints in the virtualization
technology. Factors include:
• Processor architecture requirements.
• The number of required processors.
• Memory requirements.
• Graphics adapter requirements.
• Special hardware requirements.
Windows Server 2008 Hyper-V has the following constraints and limitations:
• Is available with Windows Server 2008.
• Requires specialized hardware chipset (Intel VT or AMD-V).
• No access to USB devices or hardware such as Host Bus Adapters (HBAs).
Virtual Server 2005 has the following constraints and limitations:
• Support for up to 3.6 gigabytes (GB) of virtual memory in each guest.
• Support for 32-bit applications.
• Support for a single virtual CPU.
• No access to USB devices or hardware such as Host Bus Adapters (HBAs).
Other technical considerations related to storage and networking are covered during
steps 12 and 13 later in this guide. To ensure compatibility, IT staff members, users, and
application support staff should verify applications by running them within a VM.
In addition to verifying technical compatibility, verify that the application vendor will
support the application when used in a virtual workload. Also, consider the suitability of
an application for virtualization. Security and/or other business requirements may lead an
organization to run an application on physical hardware rather than virtually.
Task 2: Document the List of Applications

Most organizations run multiple operating systems, applications, and services that IT may
consider moving to a virtual environment. To ensure that no important considerations are
overlooked, a spreadsheet or table should be created that lists the applications, whether
they are compatible with virtualization, and whether it is appropriate to virtualize them.
Such a job aid could also include additional notes, requirements, and concerns. Filling
out such a table can provide a very helpful structure to the process of planning for
virtualization. Table 3 provides an example of information to include; the full table is
shown in the appendix at the end of this document.

Table 3. Applications That Could Be Virtualized

Application Description Application Application Is the Approved
name /purpose owner version application by
supported business
as virtual?
Microsoft Server 2007 Yes Yes
Outlook® Admin
Web Access
Microsoft IT Service 2007 Yes Yes
System Desk
Center
Essentials
Application
3
Application
4
…
This initial list serves as the basis for designing the virtualization infrastructure.

To ensure that the list of applications for virtualization is accurate, ask business
stakeholders the following questions:
• Is the list of applications complete? The success of the virtual infrastructure
design depends on determining requirements for applications that can be supported
in a virtual environment.
• Are there applications on the list that should not be virtualized? It is often
difficult to determine all the potential issues with virtualization based on technical
details alone. The fact that a workload can be virtualized does not necessarily mean
that it should be. Business leaders should understand the basic idea behind
virtualization and should verify that it appears to be a suitable solution for each
workload.
• Can the business accept the risks of moving to virtualization? Making changes
to any application or server involves risk. The business should ensure that the level
of risk is acceptable.
• Do specific legal requirements prevent an application from running within a
VM? Requirements related to physical isolation of applications or that prevent certain
applications from running on the same servers can prevent the use of virtualization.
Another legal consideration is whether the application is licensed for use in a
virtualized environment.
• Do support-related requirements prevent an application from being virtualized?
Organizations should consider support contracts and associated technical
requirements before committing to run an application within a VM.
• How should applications be prioritized? Businesses should prioritize applications
based on importance.
• Do scheduling issues exist? Some applications may have availability requirements
that prevent downtime during certain times of the year. If the time frame of the project
is fixed, this may affect which applications are considered virtualization candidates.

• What about applications that are used only rarely? Applications that are rarely
used might translate to a lower priority or might be removed entirely from the list of
virtualized applications. Alternatively, they may prove excellent candidates since
virtualization may offer a way to eliminate server hardware that runs all year, but is
hardly ever used.
• Can business users assist in testing application compatibility? Although IT
departments are responsible for deploying and supporting applications, business
users are often experts in application functionality. Compatibility tests should involve
input from representative users who can verify that their programs are running
properly in the virtual environment.
Decision Summary
The list of applications considered for virtualization should begin with an analysis of the
technical requirements of each operating system, application, and service. Good
virtualization candidates are not only technically compatible with Windows Server 2008
Hyper-V or Virtual Server 2005, but also deliver business value and conform to business
restrictions. The final list should include input from all affected users.
Additional Reading
• Solution Accelerator for Consolidating and Migrating LOB Applications at
http://www.microsoft.com/technet/solutionaccelerators/ucs/lob/lobsa/default.mspx
provides information and details on moving workloads to a virtual environment.
• Virtual Server 2005 Frequently Asked Questions at
http://www.microsoft.com/windowsserversystem/virtualserver/evaluation/virtualization
faq.mspx provides information on the features, capabilities, and limitations of Virtual
Server 2005.

Step 3: Determine Resource

Requirements
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

Application Application 1 Application 2 Application N Total
CPU % 60 30
Memory 2048 1024
Disk Capacity 500 GB 20 GB
Disk (IOPS) 750 100
Network 800 mbps 100 mbps
Bandwidth
Number of NICs 1 1
Backup Guest Level None
Fault Tolerance Yes Yes
Availability MSCS Load Balance
Approach
Physical Isolation Yes No
requirement
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
Object Counter Instance
Processor % Processor Time _Total
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

Memory Committed Bytes N/A
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
Physical Disk Disk Reads/sec _Total
Physical Disk Disk Writes /sec _Total
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
Network Interface Bytes Total / sec (Specific network adapters)
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.


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.

Step 4: Select the Backup Approach for

Each Application
The backup approach selected for the virtualized applications affects the storage and
network infrastructure of the host system. Several approaches are available for meeting
applications’ backup and restore requirements.
There are three basic options for performing backups for the applications identified in
step 4. In this step, each application is reviewed to determine which backup approach to
use. The decision should be recorded in the job aid chart.
Option 1: Per Application

Products such as SQL Server and Exchange Server have specific backup application
requirements to ensure that a complete backup is obtained. That is, ensure that not only
the data files are backed up but also that transactions in memory and transaction log files
are committed to the database.
Performing application-level backups has several useful benefits. First, the backup-
related functionality is typically designed specifically for protecting an application. It helps
ensure that files that are typically in use are backed up in a consistent state. Additionally,
the restore process is often simplified because administrators can use application-level
features to bring data back online. The backup files themselves can be significantly
smaller than those generated from a guest- or host-level backup.
Application-specific backups can have a significant impact on the host system from a
CPU, disk, and network usage perspective.
Option 2: By Guest
In guest-level backups, VMs essentially function the same as physical machines. Each
computer may include a backup agent responsible for transferring backups to a
designated storage location, or they can use the native Windows Backup application.
Guest-based backups can have a significant impact on the host system from a CPU,
disk, and network usage perspective.
Option 3: By Host
When performing backups at the host level, two options are available with Virtual Server
2005 R2 SP1:
• Offline backups. This approach requires turning off the VM or placing it in a saved
state before copying files. After the copy process is complete, the VM can be started
again. This approach involves downtime for each VM, but it provides a simple
method for implementing complete backups.
• Online backups. Using snapshot technology such as Volume Shadow Copy Service
(VSS), administrators can make copies of VM configuration files while the VM is
running. Doing so avoids downtime but may affect performance momentarily. This
option is only available on hosts using Storage Area Networks (SANs) that have a
VSS writer available.
The reason for understanding the type of backup approach for each application is to:
• Allow for the possibility of grouping VMs with similar backup requirements onto the
same hosts (for example, all VMs using host backup are placed on the same host).
• Determine the impact that backups will have on the host system from a CPU,
network, and disk usage perspective.


Additional characteristics to consider include are discussed in the following tables.
Per Different backup methods must be used for different H
application applications.
By guest Backup options can be centrally managed using enterprise M
backup software.
By host Requires no knowledge of the VM’s contents; therefore, M
backups can be performed consistently across the entire
environment.
Performance Justification
Per Backups include only important data. ↓
application
By guest Backups are treated the same as physical machines and can ↓
include the operating system, program files, and user data.
By host Backups include the entire contents of a VM, usually requiring →
more time and storage space. However, backups can be
performed while the VM is turned on.

Technical requirements often drive decisions about specific backup approaches.
However, be sure to ask the following questions to ensure that business needs are met:
• Is it necessary to back up all the content for a specific workload or application?
In some cases, application experts might determine that it is necessary to store only
certain information in backup files because users can easily re-create other data in
the event of a failure.
• Will the determined approach meet data loss requirements? Perform backups
frequently enough to ensure that data loss is minimized for critical applications.
• Does the recommended approach meet recovery requirements? Business users
will likely have expectations related to the amount of time required to recover from
various failure scenarios.
Based on answers to these questions, backup-related decisions for specific applications
may need to be reviewed and revised.
Decision Summary
At the end of this step, sufficient information about the expected backup approach for
each application that will move to a virtual infrastructure should be available. In some
cases, it may be desirable to note which backup strategies are possible and which are
preferred based on the needs of the VM.
Additional Reading
The Windows Server TechCenter article, “Backing up and restoring Virtual Server,” at
http://www.microsoft.com/technet/prodtechnol/virtualserver/2005/proddocs/vs_operate_u
sing_backUp.mspx?mfr=true addresses considerations for implementing Virtual
Server 2005 backups.

Step 5: Applying Fault Tolerance

Application fault tolerance requirements place specific technical requirements on the
virtualization host server, storage, and network infrastructure. In this step, the most
appropriate fault tolerance approach for each application that will be virtualized will be
selected. The technical approach can vary based on the details of the underlying
operating system and applications that are running in the virtual environment. Some
workloads (such as Web servers, database servers, and messaging servers) have their
own methods of implementing fault tolerance. For example, a Web server can store
session state information in a shared memory space or in a database, so the services
can automatically fail-over to another node without causing a disruption in service.
Cluster-aware applications can rely on operating system functionality such as Microsoft
Cluster Services to provide automatic fail-over. For applications that do not provide their
own fault tolerance methods, it is possible to use virtualization fault tolerance options.
In this step, map the requirements identified in step 3 to specific options for implementing
high-availability virtual systems.
Option 1: Network Load Balancing

Stateless applications such as Web servers can have fault tolerance support by
establishing network load balancing across multiple identical instances of the application.
Network load balancing technology distributes the inbound traffic headed for the
application across multiple machines running the same application, which allows for one
server to fail and the remaining servers to pick up the load. Windows Server has a
software implementation of network load balancing built in.
A hardware network load balancing solution can distribute requests based on a variety of
load-distribution algorithms. It can also monitor various nodes in the server farm and
ensure that they are operating properly before sending requests to them.
This option requires that at least one additional VM be added for each application using
network load balancing.
Option 2: Application-Specific Clustering

Many enterprise applications that customers consider mission critical have fail over
capabilities built into them through cluster awareness. These applications were designed
and built to run on an MSCS cluster. Examples include SQL Server and Exchange
Server. An MSCS cluster can be configured by using multiple VMs that have a common
shared disk.
This option requires that at least one additional VM be added for each VM that is being
clustered.
Option 3: Host Clustering

A significant number of applications cannot effectively use network load balancing and
were never designed to be cluster aware. However, one additional option can help
mitigate the exposure of a failure of systems running these applications.
The Virtual Server 2005 host system itself can be configured in an MSCS cluster. In this
configuration, if the host server running the VMs fails, the Virtual Server 2005 application
and all its VMs fail over to another node in the MSCS cluster.
The cluster would then attempt to restart each VM on the new node of the cluster. Note
that because none of the applications inside each VM are cluster aware, there is no
guarantee that the application will restart in the correct manner.


Network load Can be implemented independent of the application M
balancing technology (assuming that workloads support this
approach).
Application- Requires expertise in several high-availability approaches H
specific and procedures.
clustering
Host clustering Uses a standard approach for protecting against host H
failures but requires cluster configuration.
Cost Justification
Network load Can be implemented in software or commodity hardware. M
balancing
Application- Shared storage and configuration requirements increase H
specific cost.
clustering
Host clustering Protects against VM and host failures. H
Fault Tolerance Justification

Network load If appropriate for the application, provides a highly ↑
balancing scalable and resilient method of ensuring reliability.
Application- If available for the application, provides a highly resilient ↑
specific method of ensuring reliability.
clustering
Host clustering Protects against VM and host failures. →
Network load Delivers a high performance solution through load ↑
balancing balancing.
Application- Clustering does not significantly affect performance. →
specific
clustering
Host clustering Clustering does not significantly affect performance. →
Scalability Justification
Network load Can be scaled out to the largest implementations. ↑
balancing
Application- Can be scaled up, but at additional cost. →
specific
clustering
Host clustering Can be scaled up, but at additional cost. →


Because numerous technical considerations are involved in each fault tolerance
approach, ensure that technical decisions meet business requirements. Specific
questions to ask include:
• Are all critical areas of the application infrastructure protected? It is easy to
focus on protecting applications by themselves. However, fault tolerance requires a
focus on areas such as the power infrastructure, the network, and storage devices.
Applications might have dependencies on a wide array of services, all of which must
remain available to support mission-critical activities.
Decision Summary
The process of determining the best fault tolerance approach for specific applications
involves many considerations. For applications that support these approaches,
application-level and network-level clustering offer simplified implementation and
management.
Additional Reading
• The following white papers and articles discuss clustering options for VMs and Virtual
Server 2005:
• “An Overview of Windows Clustering Technologies: Server Clusters and Network
Load Balancing” at
http://technet2.microsoft.com/windowsserver/en/library/c35dd48b-4fbc-4eee-
8e5c-2a9a35cf63b21033.mspx?mfr=true
• “Server Clusters: Cluster Configuration Best Practices for Windows Server 2003”
at http://technet2.microsoft.com/windowsserver/en/library/5172c43a-2e6d-4d94-
bd44-163a8735ef921033.mspx?mfr=true
• “Clustering virtual machines” at
http://technet2.microsoft.com/windowsserver/en/library/73b03235-bad1-4ca8-
939f-c507d00e273f1033.mspx?mfr=true
• The Microsoft TechNet article, “NLB Design Process,” at
http://technet2.microsoft.com/windowsserver/en/library/251c6d81-b2c7-43eb-892c-
2488a57ec9a81033.mspx?mfr=true provides information about implementing
Network Load Balancing Service (NLBS) on Windows Server 2003.

Step 6: Summarize and Analyze the

Application Requirements
In preceding steps, information about specific technical and business requirements for
the applications that will move to a virtual infrastructure was collected. In step 6, this
information is combined in order to summarize the overall host requirements for the
solution. By the end of this step, sufficient information will be available to start designing
the host infrastructure.
Task 1: Summarize Guest Hardware

Resource Requirements
To determine the total host hardware resource requirements, consider the requirements
of each workload that will run in the virtual infrastructure. The sum of this information will
be used to determine the total hardware requirements for the host infrastructure. This
information will also be used in later steps to design the virtual environment.
Considerations include:
• CPU. Total the CPU requirements. The final number represents the total CPU
capacity requirements for the host hardware pool. There is no convenient method for
converting the CPU utilization usage on one processor type to another newer type so
some assumptions may be required.
• Memory. The total physical RAM requirements obtained by using application
estimates or production performance data. The result should be a value for the total
amount of memory in gigabytes that the virtual machines require.
• Disk (storage capacity). The specific storage requirements should include the
required amount of disk space for all the virtual hard disks created for VMs.
• Disk (performance). Total the IOps requirements to obtain a view of the total disk
performance requirements.
• Network. To determine host network requirements, total the peak values of network
bandwidth use. Express the result in megabits per second (Mbps) and the number of
network cards.
Record the sum of the gathered statistics in the spreadsheet that was created earlier.
This information helps in estimating the total hardware capacity required for the virtual
infrastructure.
Note To provide a safeguard against underestimating resource requirements, add “buffer”
amounts when determining specific host requirements. Obtain this by adding additional capacity
for each application or by using a percentage or constant adjustment for all applications.
Task 2: Group Applications

Use business and technical requirements to determine which workloads to combine on
which virtual servers. This information is collected in steps 1–5. Considerations include:
• Backup requirements and approach.
• Coexistence and compatibility of workloads.
• Physical isolation requirements.
• High-availability requirements.
Group VMs that have similar requirements to indicate that they might be able to run
concurrently on the same host servers.

Decision Summary
By the end of this step, a spreadsheet or database that summarizes all the requirements
for the applications and operating systems that will move to the virtual infrastructure
should be completed.

Step 7: Select a Form Factor for the

Hosts
In this step, begin to design the host infrastructure based on workload requirements
collected in the preceding steps. The goal of step 7 is to determine the most appropriate
type of host hardware on which to deploy the VMs. In making the selection, take account
of the prerequisites for the virtualization platform, whether Windows Server 2008 Hyper-V
or Virtual Server 2005 R2 SP1. The characteristics of each option also depend on the
organization’s current and planned hardware investments.
Note Form factor here refers to CPU and RAM. Later sections in this guide discuss disk space
and network requirements.
Option 1: Use Existing Hardware

In many cases, organizations already have host hardware resources that can be
reconfigured and redeployed to support the virtual workload. For example, in a server-
consolidation scenario, the goal is to increase overall hardware use by combining
workloads onto fewer physical host computers.
These machines can differ significantly based on the age of the hardware, the system
specifications, and other capabilities. Often, using existing hardware can decrease overall
costs of implementing a virtual infrastructure (cost avoidance) but may result in sacrificing
standardization. The primary drawback for using existing machines is that the hardware
configuration might not match the “ideal” configurations for the host system.
Option 2: Purchase New Hardware

When purchasing new hardware, the organization has the opportunity to set a hardware
configuration standard that can be used throughout the company. In some cases,
organizations can acquire already-approved server form factors. In other cases,
considering newer server specifications that provide increased scalability is more
appropriate. Organizations should be prepared to complete significant evaluation and
performance testing of host hardware platforms before making significant investments.
Considerations include the following:
• Scaling up versus scaling out. Fewer servers with large memory and CPU support
can be easier to manage and can be more cost-efficient for some infrastructures.
Using smaller, commodity servers with lower capacity can involve a smaller capital
outlay but often requires additional management effort.
• Fault tolerance features. The hardware configuration for new servers should
support fault tolerance and fault tolerance features based on application
requirements.
• Hardware management features. Organizations should consider purchasing
servers that support the online addition of components such as network adapters and
memory to reduce downtime and simplify administration.
It may be necessary to review this step and the defined strategy when applications are
actually allocated to each system. It is not uncommon to iterate several times through
form factor decisions to find the optimal configuration.


Use existing Organizations that have not standardized on specific M
hardware hardware configurations must maintain many different
types of systems. Legacy host hardware can also be
difficult to manage.
Purchase new New servers often come with built-in distributed L
hardware management features. Using standardized platforms can
simplify systems administration.
Cost Justification
Use existing Provides the lowest initial cost but might add to recurring L
hardware cost based on management of older hardware platforms.
Purchase new Requires significant capital expenditures to create and H
hardware deploy new hardware for the virtual infrastructure.

Ask the following questions to verify that the host hardware approach meets the
organization’s business requirements and directions:
• What is the total budget for implementing the virtual infrastructure? Details help
define options for purchasing and deploying new hardware. Budget constraints might
necessitate changes to the list of applications that can be supported in the virtual
infrastructure.
• Are the hardware estimates aligned with purchasing goals? Factoring in current
and future purchasing decisions is a necessary step in designing the virtual
infrastructure.
• Will the business realize the cost reductions and savings it anticipates? Often,
Total Cost of Ownership (TCO) and Return on Investment (ROI) numbers must be
calculated to ensure that the organization will achieve the expected benefits.
Decision Summary
Determining the optimal hardware configuration for the virtual infrastructure should
involve an inventory of existing host hardware systems. Compare resource specifications
to the requirements summarized in step 6 to determine whether new purchases will be
required or would be optimal. Business constraints play a crucial role in determining the
most appropriate approach for the organization.

Step 8: Determine Server Placement

Details about the scope of virtualization were generated in step 1, and this information
will be used to determine the placement of host servers. Organizations should consider
the overall goals of centralization, regionalization, and decentralization when deciding
where to deploy servers.
IT can deploy virtualization host servers to many areas of the organization, depending on
the needs of virtual workloads. The purpose of step 8 is to choose the most appropriate
approach for determining where servers should go. Specific decisions are based on user
needs in addition to business and technical requirements. If IT will support several
different scenarios within the virtual infrastructure, it is likely that all options will be used.
Option 1: Enterprise Deployment

The default location for the majority of corporate resources is typically within one or more
corporate data centers. These environments are designed to support a large number of
physical computers. They tend to have on-site systems administrators who have
expertise in deploying, monitoring, and troubleshooting hardware-related issues. As
described in step 7, organizations can choose to keep existing hardware within the data
center and use it to form the basis of a virtual infrastructure, or they can purchase and
deploy new hardware.
The primary advantages of locating servers in a data center include the ability to achieve
centralized management and reduced costs because of a shared power, cooling, and
network infrastructure. Other components such as SANs can help increase scalability.
However, constraints related to data center capacity might necessitate moving servers to
other locations.
Option 2: Hub Deployment

Business and technical needs can often require that virtual workloads be geographically
distributed. Considerations are based on user requirements for virtual workloads. In most
organizations, remote offices and satellite locations are connected by relatively low-
bandwidth network links. This raises the need to deploy systems that are located
physically closer to application users. Other reasons for distributed host deployment
include meeting the needs of independent business units.
Option 3: Satellite Deployment

Satellite deployments use a decentralized approach for host server placement. For
example, an organization that has a franchise model might have specific business
requirements for placing host servers within each location.


Place host Centralizing the infrastructure in a single location will result L
servers in a in a less complex deployment that will likely be easier to
data center manage.
Place host Distributing infrastructure components across additional M
servers in hub sites will require more co-ordination of resources between
offices the sites.
Place host Coordinating resources across satellite locations will H
servers in a increase the complexity of the implementation.
satellite office
Cost Justification
Place host Generally, deploying systems in a data center can be far less L
servers in a costly than deploying them to remote locations. By using
data center existing data center features and expertise, costs are lower
overall.
Place host Supporting host servers in remote sites can be expensive, M
servers in hub especially for sites that do not already have the necessary
offices server infrastructure.
Place host Supporting host servers in satellite offices will be expensive H
servers in a because the necessary server infrastructure is unlikely to be
satellite office in place and there will not be skilled staff on-site.
Security Justification
Place host IT organizations can ensure that centralized data centers are ↑
servers in a in compliance with security and regulatory requirements.
data center Systems administrators can be dedicated to ensuring that
systems remain properly configured.
Place host Remote sites typically lack the expertise and resources to →
servers in hub ensure that systems have adequate physical security.
offices
Place host In remote satellite offices, it is more difficult to guarantee the ↓
servers in a physical security of infrastructure components.
satellite office


Server-placement decisions affect all areas of the organization and can significantly affect
costs and the overall user experience. Questions to ask include:
• Does the current design support future business expansion? Organizations that
are planning additional sites and locations should take into account future plans when
considering server placement.
• Are the server placement decisions in accordance with regulatory and security
compliance requirements? Organizations might have a business need to store
certain types of data and applications within the corporate data center.
• Does the organization have the expertise to support servers in the defined
locations? Larger branch offices tend to have dedicated IT staff, whereas smaller
environments do not.
• Are there any geopolitical considerations? Are there any international boundaries
that need to be considered?
Decision Summary
Physically centralizing host servers within one or more corporate data center offers
numerous advantages in security and availability. These benefits can help reduce costs
for the virtual infrastructure. Specific needs in geographically distributed organizations
can, however, necessitate the deployment of applications into other locations. In general,
place servers within a data center whenever it is possible, and move servers to remote
locations only when it is absolutely required.
Additional Reading
Solution Accelerator for Consolidating and Migrating LOB Applications at
http://www.microsoft.com/technet/solutionaccelerators/ucs/lob/lobsa/lobsaplg.mspx
includes information on deployment planning for various applications and workloads
using Virtual Server 2005.

Step 9: Map Guests to Hosts

The purpose of step 9 is to determine which specific applications will be placed on which
specific physical hosts. The mapping process involves using information collected in
previous steps. For example, if several applications are unable to coexist on a server
based on physical security or coexistence issues, they must be mapped onto different
host servers.
Task 1: Determine Host Resource Limits

The overall process of determining the ideal mapping of guest computers to specific
hosts can require significant effort. The process of taking into account the many different
considerations for resources and other requirements can lead to many viable options
worth considering. Additionally, workload characteristics can change over time. Therefore,
consider details such as target host resource use.
Determine the Threshold/Buffer Plan

From the standpoint of host servers, the organization must decide on the optimum host
resource use levels. One approach is to maximize resource use on each host while
leaving sufficient “head room” for handling unexpected peaks in use patterns. For
example, it might be determined that the optimum CPU utilization for virtualization host
servers is 80 percent.
Task 2: Map Guests to the Form Factor

This task involves allocating the guest-related workload requirements (summarized in
step 6) to the physical host machines.
Use information about specific VM resource requirements to determine how best to place
VMs. For example, categorize workloads based on their CPU requirements. In addition to
resource requirements, consider combining or separating those applications based on
backup, availability, and isolation requirements. For example, if entire VM backup is
required, deploy the application onto servers designated for this method.
Ideally, this process would be likened to an automatic coin counter where all of the coins
are put in a funnel in the top of the machine and the coins are automatically separated
into their respective denominations and stacked in sizes that fit the coin wrappers. When
a stack is full, the machine stops until the full wrapper is removed and a new one is
positioned.
Unfortunately, most of this process is manual today so it is more analogous to a child’s
shape sorting toy where each object must be manually placed into the right location.
The goal of this part of the design is to map all the applications onto as few physical
servers as possible in each geography while still respecting the needs for server buffer,
isolation, availability, backup type, and so on.
At the end of this exercise, all applications and requirements should be accounted for and
the number of physical servers should be identified. Additional servers may be required to
meet fault tolerance requirements. These are addressed later in this guide. It may be
appropriate to iterate through this process using different form factor designs to find the
optimal configuration.


IT can complete resource-related requirements for mapping guests to the host
infrastructure. However, other details, such as fault tolerance and backup requirements,
should be verified with the business. Considerations include:
• Are these decisions consistent with the organization’s goals for virtualization?
Determine the method of workload allocation based on the expected business
benefits of adding a virtual infrastructure.
• Does the current design meet the organization’s availability and backup
requirements? Details such as host server placement, facility limitations, and
systems administrator expertise can affect overall operations.
• Which requirements and constraints can be considered flexible? In some cases,
businesses might find that relatively small investments in additional hardware can
lead to better overall workload distribution decisions. The organization should
reconsider details such as budgets and employee resources based on results from
this step.
Decision Summary
Determining how best to distribute guest workloads onto a virtual infrastructure can take
significant time and effort. The specific considerations vary widely based on the number
and type of applications to be supported in addition to preliminary decisions based on the
host hardware infrastructure. Plan to regularly review these decisions after making
changes to either the guest or host requirements.

Step 10: Determine the Host Backup

Approach
The purpose of this step is to determine the backup approach that host servers will use to
meet the application requirements defined in steps 1–6. This information will be used to
determine storage and network requirements in subsequent steps.
In this step, two main approaches to backing up virtual workloads are presented. The
guest-related backup requirements are important for informing host backup decisions.
Since backup requirements are based primarily on recovery requirements, familiarity with
the downtime and data-loss limitations for each workload is important. The results of this
step help determine requirements for the storage and network infrastructure.
Because the entire contents of a VM are encapsulated in virtual hard drive (VHD) and
configuration files, a simple method of performing backups is to copy these files from the
host computer’s file system. One of the advantages of this approach is that
administrators can create the backups for any guest operating system. Also, the restore
process is simplified because administrators can restore the VM using a simple file copy
process. In addition to backing up the host system itself, the host-level backup process
can be performed in a variety of ways that affect the guest systems, but the primary
challenge is that VHD files are locked as “in use” while VMs are running. One solution
involves temporarily pausing or shutting down a VM before starting backups. However,
doing so requires downtime and an interruption to application availability. Other options
include performing snapshot-based backups directly from the storage system.
Virtual Server 2005 R2 with Service Pack 1 (SP1) supports VSS to make consistent
backups of VMs while they are in use. Windows Server 2008 Hyper-V does not support
VSS at the time of writing.
Host-level backups will have an impact on the performance of the server. They can also
affect the capacity and performance of the disk and network subsystems. It is necessary
to account for these impacts in the form factor buffer as well as the network and disk
capacity and performance planning considerations.

Cost Justification
VM shut down Generally requires less disk space and can use existing L
for host enterprise backup solutions (if available).
backup
VSS snapshot Requires enough disk space to store copies of all VM H
content.
VM shut down The VM is down while backup occurs. ↓
for host
backup
VSS snapshot Minimal effect on performance. →


The specified backup approach can have a significant effect on the business. To validate
its decisions, ask the following questions:
• Are there special disaster recovery requirements for the backup solution? In
some cases, it might be much easier to maintain a disaster recovery site using full
VM backups. In other cases, file system replication or other technologies might be
more appropriate.
• How are data-protection requirements expected to change in the future? Although
this question can be difficult to answer, factoring in anticipated enterprise application
deployments can help the organization decide how best to invest in storage capacity
to support the selected backup approach.
Decision Summary
Many organizations choose to use both guest- and host-level backups for specific
applications and workloads. The key concept in considering host backup choices is to
recognize and plan for the impact the backup strategy will have on guest and host
availability, performance, and capacity planning.
Additional Reading
• See the Windows Server TechCenter article, “Backing up and restoring Virtual
Server,” at http://technet2.microsoft.com/windowsserver/en/library/d7c25b9e-dab6-
425c-95d2-b085825e95891033.mspx?mfr=true.
• See the Microsoft Knowledge Base article, “How to back up virtual machines in
Virtual Server 2005,” at http://support.microsoft.com/kb/867590. Note that Virtual
Server 2005 R2 with SP1 supports VSS.

Step 11: Design Fault Tolerance

In step 5, information was collected on the → requirements for all the workloads that IT
will support in the virtual infrastructure. In this step, this information is used to design the
fault tolerance solutions for server virtualization host hardware.
Task 1: Apply Load Balancing

For each application identified in step 5 that required network load balancing, determine
how many additional VM instances of the application are needed, and then map them
onto physical host systems in the same way as for the original VMs in step 9. Ideally, load
balanced VMs should be distributed across multiple hosts to protect against the failure of
a single host taking down all instances of the load-balanced application. Each load-
balanced VM adds at least one more VM and often several to the list of VMs that need to
be placed in the infrastructure.
Task 2: Plan for Host Clustering

In step 9, all the applications were mapped onto physical host servers. Count the number
of physical servers that have applications requiring an MSCS cluster or host cluster as
defined in step 5. This number represents the number of active cluster nodes required.
Then, build an MSCS cluster plan that supports this defined number of active nodes.
Each MSCS fail over cluster will require at least one additional physical host server to act
as the passive node in the cluster.

As in preceding steps related to fault tolerance, it is important to validate decisions based
on input from the business. Questions should include:
• Are there nontechnical availability needs for specific applications? Some users
might require a way to access applications while disconnected from the network or
while working at occasionally connected remote sites. These considerations can
affect the host fault tolerance design.
• What are the future capacity needs for the virtual infrastructure? Conferring with
the business will help the business plan for future expansion.
• Will future application versions provide more availability options? Newer
versions of applications might provide enhanced fault tolerance capabilities that can
allow less expensive options to be used.

Decision Summary
Host clustering can provide a simple method of ensuring that many types of VMs remain
available even after the failure of a host system. The costs of implementing host
clustering, however, can be significant because of hardware and storage requirements.
Additionally, unused capacity on standby nodes and servers lowers overall hardware
resource use.
Additional Reading
• Virtual Server Host Clustering Step-by-Step Guide for Virtual Server 2005 R2 at
http://www.microsoft.com/downloads/details.aspx?FamilyID=09cc042b-154f-4eba-
a548-89282d6eb1b3&displaylang=en provides information about implementing host-
level clustering in Virtual Server 2005.
• The Microsoft Knowledge Base article, “Requirements for configuring clustering in
Virtual Server 2005,” at http://support.microsoft.com/kb/840192 provides
implementation details for enabling clustering.

Step 12: Design the Storage

Infrastructure
In a virtualization environment, the infrastructure must be able to provide large amounts
of storage space to support many different VMs. Fortunately, many options exist for
scaling storage based on overall workload requirements. Step 12 presents considerations
for designing the storage infrastructure for server virtualization.
Infrastructure storage planning consists of two primary considerations: planning for
performance and planning for capacity.
Task 1: Plan for Performance

The goal of designing storage to meet disk performance requirements is to support the
required number of IOps. This information was collected in step 2 and totaled in step 6 to
arrive at the total disk performance requirement.
In this task, calculate the IOps requirements for each physical server by totaling the IOps
requirements for each application on each server. This will give the IOps requirement per
server because each host server may be connected to a different storage system. The
choice of disk redundancy levels such as RAID 1 or RAID 0+1 affects the IOps
calculation. By mapping this IOps requirement to the selected type of disk subsystem and
the drive characteristics of that subsystem, it is possible to determine the number of
actual drives required to achieve the performance objectives. Remember to consider
host-based activities in your planning such as the impact of backup operations on disk
performance as well as adding an appropriate buffer to protect the system in the event of
any system performance anomalies.
Task 2: Plan for Capacity

In this task, calculate the disk capacity requirements for each physical server by totaling
the capacity requirements for each application on each server plus the space that
backups need (if any). Doing so gives the disk capacity requirement per server because
each host server may be connected to a different storage system.
Redundant Arrays of Independent Disks (RAID) can be used to provide fault tolerance
and to improve performance of disk arrays. Common RAID options for production
virtualization host servers include RAID 1 (Disk Mirroring), RAID 5 (Disk Striping with
Parity), and RAID 0+1 (Mirror Stripe Sets). Each option offers a different portfolio of
capacity, performance, and cost.
By mapping this disk capacity requirement plus the RAID configuration to the size of
disks in the selected subsystem, it is possible to determine the number of actual drives
required for performance.
Note The actual number of disks required is the greater of the number determined in Task 1
(performance) and the number determined in Task 2 (capacity). Usually that will be the number
determined by performance.

Task 3: Select an I/O Form Factor

A primary challenge of implementing a storage infrastructure is maintaining
manageability. When working with local storage, a typical data center can include
hundreds of individual hard disks and storage volumes. The result is increased
management effort and wasted disk space (because of unused storage resources on
each computer). Using network-based storage solutions, organizations can centralize
their storage management by storing data on the network.
The choice of the form factor for the storage system should reflect the ability to provide
the performance and capacity requirements as well as clustering support, if applicable,
and VSS snapshot backup capabilities, if required.
Additional Reading
• The TechNet Webcast Working with the VHD File Format in Virtual Server 2005
(Level 3000) at
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-
US&EventID=1032284293&CountryCode=US provides details on the different VHD
types available in Virtual Server 2005.
• The Windows Server TechCenter article, “Creating virtual hard disks in Virtual
Server,” at http://technet2.microsoft.com/windowsserver/en/library/c1726ff8-ea2b-
41b1-8cc8-7ec5848d813e1033.mspx?mfr=true provides details on the architecture of
different VHD types in Microsoft Virtual Server.
• The white paper, “Using iSCSI with Virtual Server 2005 R2,” at
http://www.microsoft.com/downloads/details.aspx?FamilyID=d112aa63-a51e-4722-
a41b-98b3ab3700a3&displaylang=en provides information on using iSCSI initiators
in a Virtual Server 2005 environment.
• The Microsoft TechNet article, “Using a storage area network with virtual machines,”
at
http://www.microsoft.com/technet/prodtechnol/virtualserver/2005/proddocs/vs_deploy
_SAN.mspx?mfr=true provides information on SAN design for a virtual infrastructure.

Step 13: Design the Network

Infrastructure
Most production applications require access to the network in order to communicate with
users and other VMs. Additionally; the server virtualization hosts require connections for
management, backup, and storage purposes. Consider these requirements when
determining the network configuration for the server virtualization infrastructure. Using the
application requirements collected in step 2 and the physical server designs in steps 9–
12, for each host server, determine the number of physical network adapters and the total
throughput requirements. Also, consider redundancy for implementing fault tolerance.
The business and technical requirements for each application to be deployed to the
virtual network infrastructure should drive these decisions.
Task 1: Determine Host Connectivity

Requirements
Windows Server 2008 Hyper-V and Virtual Server 2005 provide the ability to configure
network settings based on application requirements. Several options exist for defining
network access settings for VMs:
• No network connectivity. In this configuration, the VM does not have network
access to other VMs or physical servers.
• VM-only (logical) networks. For security purposes, VMs can be configured to
communicate only with other VMs that are on the same host computer.
• Physical network access. This method allows VMs to exist on production host
networks similar to physical computers.
Design the number and types of network connections that will be required based on
applications’ needs. The general rule should be to provide each VM with minimal network
access based on specific application requirements. Doing so helps ensure security and
reduces network traffic.
Task 2: Determine Host Throughput

Requirements
In step 3, the amount of required network bandwidth for each VM to be deployed to the
server virtualization infrastructure was established. Translate this information into specific
host network requirements based on which VMs will reside on which servers. In the
simplest configuration, a single physical host server network interface might be sufficient
to handle the needs of all the VMs on a server. More often, performance and security
requirements will require additional physical ports. The following types of connections are
common for server virtualization deployments:
• Private network access. Applications that must have dedicated communication with
other VMs. Physical servers such as a cluster heartbeat should be placed on private
network segments through the host’s physical network adapter.
• Public network access. These networks allow external traffic for publicly accessible
VMs such as Web servers. For security purposes, use separate physical network
connections in this case.
• VM networks. Create physical network connections that isolated groups of VMs
located on different host servers can use. These networks are typical in test and
development environments.

• Management networks. For security and reliability purposes, organizations can

choose to use a separate network for managing server virtualization administrative
functions. These networks are restricted to internal traffic.
• Backup networks. Use these networks for performing host- and guest-level backups
based on the specific needs of the environment.
• Storage networks. Storage-related traffic can require large amounts of free
bandwidth and low latency. Use storage network connections to provide access to
remote VHDs or to virtual operating systems to access network-based storage data.
Each network connection requires corresponding physical switch port capacity and
available bandwidth within the physical network environment.
Task 3: Plan for Network Reliability and

Availability
In addition to providing multiple network connections based on functional needs, ensure
that physical host network connections meet reliability and availability needs. Most
network vendors offer network adapter “port teaming” functionality to provide fault
tolerance. This approach works by allowing multiple physical network adapter ports to act
as a single port, ensuring reliability and availability. Features like automatic failover and
bandwidth aggregation require switch and network-layer support, and specific
configurations depend on the standards in use.
For each physical host, calculate the number of physical network adapters required. The
determinations made for this step may inform changes in the host form factor if the
selected host chassis cannot support the number of physical network cards required.

Base the specific design of network connections on application and business
requirements. To validate design decisions, ask the following questions:
• Does the design accommodate all the supported user access scenarios? When
designing virtual network access, it is often easy to overlook some segments of the
user population. Consider factors such as remote access, access from the Internet,
and support for branch offices.
• Does the network infrastructure meet security and regulatory compliance
requirements? Organizations must ensure that communications and data remain
secure in order to meet these standards. Network design should take into account
methods for managing authentication, authorization, and encryption.
Additional Reading
“Manage virtual networks” in the Virtual Server 2005 Administrator’s Guide
(http://www.microsoft.com/technet/prodtechnol/virtualserver/2005/proddocs/vs_operate_h
t_configVMN.mspx?mfr=true) provides information on the design and implementation of
various virtual network options.

Technical Note: Managing Network

Addressing
Like physical machines, VMs require unique network media access control (MAC) and IP
addresses to communicate with each other. By default, Virtual Server 2005 uses an
automatic method to create MAC addresses for virtual network adapters. When working
in a distributed environment that requires connectivity among many different virtual
systems, some MAC addresses may be reused. Consider using static MAC address
assignments to avoid this behavior.
Use the following approaches for IP address management:
• Using static IP address assignments within each VM
• Using the Virtual Server 2005 internal Dynamic Host Configuration Protocol (DHCP)
server
• Using a network-based DHCP server
Most organizations use a combination of these approaches, depending on the specific
connectivity needs of each VM.

Step 14: Validate the Overall Approach

Once a completed draft design has been established, the plan and supporting decisions
made in previous steps are compiled and presented to the business. In most
organizations, this step will be required to obtain cost approval and to approve the
virtualization project.
The process of identifying application requirements and mapping them to a server
virtualization infrastructure design requires input from people throughout the organization.
Technical requirements such as CPU, memory, disk, and network details are often the
domain of IT architects and implementers. However, to ensure that the overall design
remains aligned with the initial goals and business requirements, plan to review all
decisions and the final design with stakeholders.
Much of the host infrastructure’s design is based on having accurate information about
which applications will be virtualized. The review process should begin with a validation of
this list of applications and with an assessment of their resource requirements.
Decisions about which technology approaches to use to support the virtual infrastructure
can substantially affect an organization’s ability to meet its business goals. Details and
conclusions that must be validated include:
• Server placement.
• Server form factor.
• Guest-to-host mappings.
• Host backup approaches.
• Host high-availability approaches.
• Storage infrastructure design.
• Network infrastructure design.
Take the time to ensure that the business understands the specific implications prior to
moving forward with implementation.

Conclusion
Virtualization technology can provide dramatic benefits to nearly all aspects of an
organization’s IT environment. The ideal implementation depends on determining the
business and technical requirements for the applications to be deployed to the virtual
infrastructure. The process begins by collecting detailed information on the applications
to be deployed. Details include specific hardware resource requirements in addition to
availability, security, backup, and other considerations.
After all this information is collected and analyzed, it can be used to design the host
infrastructure. Specific decision points include determining server placement, selecting a
server form factor, mapping guests to hosts, and choosing backup and availability
approaches. Numerous considerations also exist for designing the storage and network
infrastructure to support the virtual environment.
Overall, by following an organized process for designing a server virtualization
infrastructure, organizations can help ensure that they meet business and technical
requirements.
Additional Reading
In addition to Virtual Server 2005 R2 with SP1 product documentation, the following sites
offer supplemental information on the product concepts, features, and capabilities
addressed in this guide:
• Microsoft Virtual Server 2005 R2 at
http://www.microsoft.com/windowsserversystem/virtualserver/default.aspx provides a
central location for information about the Virtual Server platform.
• Virtual Machine Technology FAQ at
http://www.microsoft.com/licensing/highlights/virtualization/faq.mspx provides
answers to commonly asked questions about Virtual Server functionality, licensing,
and deployment options.
• Microsoft TechNet Server Virtualization forum at
http://forums.microsoft.com/TechNet/ShowForum.aspx?ForumID=583&SiteID=17
provides a location in which architects, implementers, and users can discuss issues
related to designing and deploying Virtual Server.
• The white paper, “Improving IT Efficiency at Microsoft Using Virtual Server 2005,” at
http://www.microsoft.com/technet/itshowcase/content/virtualserver2005twp.mspx
provides details on how Microsoft has implemented a Virtual Server 2005
infrastructure. An associated Webcast at
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=103227699
8&EventCategory=3&culture=en-US&CountryCode=US is also available.
• See Microsoft TechNet Radio, “How Microsoft Does IT: The Future of Server
Virtualization,” at
http://www.microsoft.com/technet/community/tnradio/archive/june262007.mspx.
• Windows Server 2008 Hyper-V Library at
http://technet2.microsoft.com/windowsserver2008/en/library/5341cb70-0508-4201-
a6da-dcac1a65fd351033.mspx.
• Windows Server 2008 Hyper-V Resources at
http://www.microsoft.com/virtualization/resources.mspx#documents.

Appendix
The table used to determine and total the requirements for the virtualization infrastructure
is shown in Table 9.

Table 9. Documenting the Requirements

Acknowledgments
The Solution Accelerators - Management and Infrastructure (SA-MI) team acknowledges
and thanks the people who produced the Infrastructure Planning and Design Guide for
Windows Server Virtualization. The following people were either directly responsible for
or made a substantial contribution to the writing, development, and testing of this guide.
Project Team:
• Jeremy Chapman – Microsoft
• Charles Denny – Microsoft
• Anil Desai – Studio B
• Dave Field – Studio B
• Michael Kaczmarek – Microsoft
• Lex Liao – Microsoft
• Robin Maher – Microsoft
• Lisa Pere – Studio B
• Fergus Stewart – Microsoft
Contributors:
• Ben Armstrong – Microsoft
• René Scholten – Capgemini
• Allen Stewart – Microsoft
Editors:
• Michele Anderson – Studio B
• Laurie Dunham – Microsoft
• Kris Maxwell – Studio B
• Pat Rytkonen – Volt

IPD - Windows Server Virtualization

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IPD - Windows Server Virtualization

Uploaded by

Copyright:

Available Formats

Infrastructure Planning

Windows Server Virtualization

Published: November 2007

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Who Should Use This Document

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization in

Figure 1. Mapping of technology into Core Infrastructure Model

Infrastructure and Business Architecture

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Virtualization Design Process

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Figure 2. Decision flow diagram

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Step 1: Determine the Virtualization

Option 1: Enterprise Deployment

Option 2: Hub Deployment

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Option 3: Satellite Deployment

Evaluating the Characteristics

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Validating with the Business

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Step 2: Create the List of Applications

Task 1: Determine Application Compatibility

Task 2: Document the List of Applications

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Table 3. Applications That Could Be Virtualized

Validating with the Business

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Step 3: Determine Resource

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Table 4. Tracking Resource Requirements

Note To provide safeguards against underestimating resource requirements, add a “buffer”

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Table 6. Performance Monitor Statistics for Required Memory

For each machine being virtualized add approximately 24 megabytes of memory to

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Disk Performance Counters

Network Performance Counters

Task 7: Coexistence and Physical Isolation

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Validating with the Business

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Step 4: Select the Backup Approach for

Option 1: Per Application

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Evaluating the Characteristics

Validating with the Business

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Step 5: Applying Fault Tolerance

Option 1: Network Load Balancing

Option 2: Application-Specific Clustering

Option 3: Host Clustering

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Evaluating the Characteristics

Fault Tolerance Justification