Académique Documents
Professionnel Documents
Culture Documents
and Design
Version 1.0
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.
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.
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.
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.
Feedback
Please direct questions and comments about this guide to satfdbk@microsoft.com.
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.
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.
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.
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.
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.
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
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.
This initial list serves as the basis for designing the virtualization infrastructure.
• 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.
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.
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.
Note Similar performance counters are available for other operating systems.
Total the Physical Disk counters from the table above to calculate the IO usage for each
system. Record the values in the table.
Task 4: Network
Most workloads require access to production networks to ensure communication with
other applications and services and to communicate with users. Network requirements
include elements such as throughput—that is, the total amount of traffic that passes a
given point on a network connection per unit of time.
Other network requirements include the presence of multiple network connections.
Workloads might require access to several different networks that must remain secure.
Examples include connections for:
• Public network access.
• Networks for performing backups and other maintenance tasks.
• Dedicated remote-management connections.
• Network adapter teaming for performance and failover.
• Connections to the physical host server.
• Connections to network-based storage arrays.
Add the number of required network connections to the spreadsheet that was created
earlier.
Note Similar performance counters are available for other operating systems.
Add the values for each application, and then add the information to the spreadsheet that
was created earlier.
Task 5: Backup
Considering backup requirements for applications helps inform storage, network, and
other requirements in subsequent steps in this guide. Some types of workloads might not
require backups. For example, a Web server that presents static data might simply be
rebuilt in case of a failure. Most workloads, however, contain important configuration
settings, operating system settings, and user data that must be protected in the case of a
VM failure.
If this application requires backup, record it in the table.
Solution Accelerators microsoft.com/technet/SolutionAccelerators
Windows Server Virtualization 19
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.
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.
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.
Complexity Justification
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.
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.
Complexity Justification
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
Performance Justification
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. →
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.
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.
Complexity Justification
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.
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.
Complexity Justification
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
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.
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.
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.
Performance Justification
VM shut down The VM is down while backup occurs. ↓
for host
backup
VSS snapshot Minimal effect on performance. →
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.
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.
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.
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.
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.
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