Microsoft System Center Virtual Machine Manager 2008 R2

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 to the business in terms of cost, complexity, and other characteristics.
  • Framing the decision in terms of additional questions to the business to ensure a comprehensive understanding of the appropriate business landscape.

The guides in this series are intended to complement and augment the product documentation.

Benefits of Using This Guide

Using this guide will help an organization to plan the best architecture for the business and to deliver the most cost-effective Microsoft System Center Virtual Machine Manager (VMM) 2008 technology.

Benefits for Business Stakeholders/Decision Makers:

  • Most cost-effective design solution for an implementation. Infrastructure Planning and Design (IPD) eliminates over-architecting and overspending by precisely matching the technology solution to the business needs.
  • Alignment between the business and IT from the beginning of the design process to the end.

Benefits for Infrastructure Stakeholders/Decision Makers:

  • Authoritative guidance. Microsoft is the best source for guidance about the design of Microsoft products.
  • Business validation questions to ensure the solution meets the requirements of both business and infrastructure stakeholders.
  • High integrity design criteria that includes product limitations.
  • Fault-tolerant infrastructure, where necessary.
  • Proportionate system and network availability to meet business requirements. Infrastructure that is sized appropriately to meet business requirements.

Benefits for Consultants or Partners:

  • Rapid readiness for consulting engagements.
  • Planning and design template to standardize design and peer reviews.
  • A "leave-behind" for pre- and post-sales visits to customer sites.
  • General classroom instruction/preparation.

Benefits for the Entire Organization:

Using this guide should result in a design that will be sized, configured, and appropriately placed to deliver a solution for achieving stated business requirements, while considering the performance, capacity, manageability, and fault tolerance of the system.

Introduction to the Virtual Machine Manager Guide

This guide leads the reader through the process of planning a Virtual Machine Manager 2008 infrastructure. It addresses the following fundamental decisions and tasks:

  • Identifying the business and technical requirements for managing virtualization.
  • Determining whether to integrate Virtual Machine Manager 2008 with Microsoft System Center Operations Manager 2007 and how to design that integration.
  • Determining the number of VMM servers the organization requires, including each server's size, placement, and connectivity.

The project team should prioritize business objectives at the start of the project so that IT and business managers clearly understand and agree on them. Certain features require additional licensing or infrastructure costs. Before adding those features, the team should provide the extra cost information to the business so that it can understand the additional costs and make the best decision for the business.

Virtual Machine Manager 2008 introduces the following new features:

  • Support for Microsoft Hyper-V™ on Windows Server® 2008.
  • Support for managing VMware ESX through VMware Virtual Center.
  • Delegated administrators with user roles.
  • Support for Windows Server 2008 Failover Clusters for Hyper-V.
  • Resource calibration and optimization improvements.

What's New in System Center Virtual Machine Manager 2008 R2

This guide has been revised since version 1.2 to include new features in Virtual Machine Manager 2008 R2. There are no changes to the IPD process from Virtual Machine Manager 2008, but the guide has been refreshed with the current template and some usability improvements have been made.

VMM 2008 R2 manages many of the new capabilities of Windows Server 2008 R2 Hyper-V including:

  • Live migration—for moving virtual machines (VMs) between hosts with no downtime. VMM performs host compatibility checks and can then initiate and control the migration. This enables users to check if a VM is compatible with the destination host instead of doing the migration and then finding out that the VM cannot start on the host.
  • VMM can automate the evacuation of VMs off Hyper-V host machines—for example, to implement maintenance mode. A Hyper-V host can participate in only one live migration at any given time, both as source and destination. This means that the user has to wait for the live migration to complete before attempting another one. VMM R2 can detect the condition where live migration fails due to another live migration in progress, queue up the request in the background, and then retry the request after a period of time. This feature enables users to perform multiple live migrations without needing to keep track of other live migrations that are happening within the cluster; VMM R2 will automatically do the queuing and retries in the background.
  • Multiple virtual machines are supported on a single logical unit number (LUN) using Clustered Share Volumes. Quick Storage Migration enables migration of a VM's storage both within the same host and across hosts while the VM is running, with a minimum of downtime. The downtime depends on the amount of activity going on in the VM at the time of migration; product group tests have shown typical downtimes to be less than 2 minutes.

Assumptions

This guide assumes that the reader is familiar with VMM and virtualization technology. It also assumes that the organization is planning a VMM implementation and, if the project team chooses to integrate VMM with Operations Manager, that the organization has already planned the Operations Manager infrastructure.

To limit the scope of this guide, the following assumptions are made:

  • This guide does not address the business or technical case to make a virtualization-management solution choice.
  • This design is for use in a production environment. This guide assumes that the project team will also create a test environment to mirror the production environment in configuration.
  • The reader is familiar with Microsoft infrastructure solutions. This guide does not attempt to educate the reader on the features and capabilities of Microsoft products. The product documentation covers that information.

Virtual Machine Manager 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 http://www.microsoft.com/infrastructure.) 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 applied 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, automated, centralized management of virtual machine (VM) hosts can move an organization to the Rationalized level. On the path to the Dynamic level, organizations can use self-service provisioning to enable users to automatically provision VMs to the most suitable hosts.

Figure 1. Mapping of Virtual Machine Manager into Core Infrastructure Model

Virtual Machine Manager Design Process

The goal of this guide is to help project teams gather information, make decisions, choose options, and complete the tasks required to create and design a VMM infrastructure. The objective is an infrastructure that is sized, configured, and appropriately placed to deliver the required business benefits, while considering the user experience, manageability, performance, and capacity of the system. This guide addresses the scenarios that a project team designing a VMM infrastructure is most likely to encounter. Project teams should consider having Microsoft Customer Service and Support review their architecture prior to implementation, as that is the organization that can best comment on the supportability of a particular design.

The components of a typical VMM infrastructure are shown in Figure 2.

Figure 2. System Center Virtual Machine Manager 2008 architecture

Decisions

This guide addresses the following decisions and/or activities that need to occur in preparing for VMM planning. The seven steps below represent the most critical design elements in a well-planned VMM design:

  • Step 1: Define the Project Scope
  • Step 2: Determine Whether to Integrate with Operations Manager 2007 for Reporting
  • Step 3: Design Operations Manager Integration
  • Step 4: Determine the Number of Virtual Machine Manager Instances Required
  • Step 5: Size and Place the Virtual Machine Manager Server, SQL Server-Based Server, Database, and Web Server
  • Step 6: Size and Place the Library Servers and Libraries
  • Step 7: Design the Network Connections

Some of these items represent decisions that should be made. Where this is the case, a corresponding list of common response options will be presented.

Other items in this list represent tasks that should be carried out. These types of items are addressed because their presence is significant in order to complete the infrastructure design.

Decision Flow

Figure 3 provides a graphical overview of the steps in designing a VMM infrastructure.

Figure 3. The Virtual Machine Manager infrastructure decision flow

Information Collection

To design a VMM infrastructure using this guide, the following information is required:

  • To determine the scope of the virtualization project:
    • List of locations containing VM hosts
    • List of virtualization technologies each location uses
    • The organization's management model (centralized or decentralized)
  • To design Operations Manager integration:
    • List of Operations Manager management groups containing VM hosts
  • To size and place VMM infrastructure servers:
    • Physical network map
    • List of images and other files used by VM hosts at each location
    • List of database servers available to each location
  • To design network connections:
    • Physical network map
    • Available bandwidth between each location

Applicable Scenarios

This guide addresses considerations that are related to planning and designing the necessary components for a successful VMM infrastructure:

  • Managing VM hosts that use:
    • Hyper-V in Windows Server 2008.
    • VMware ESX through VMware Virtual Center.
    • Microsoft Virtual Server 2005 R2 with SP1.
  • Designing VMM infrastructures that organizations can use for server consolidation and self-service provisioning.
  • Designing topologies that best fit the organization's requirements, such as:
    • VMM in a data center to manage a library and all VM hosts within the data center.
    • VMM in a central location to manage libraries and VM hosts across multiple data centers.
    • Multiple instances of VMM to enable each location to manage its own libraries and VM hosts.

Out of Scope

The following topics are out of scope for this guide:

  • Planning virtualization infrastructures. This guide does not address the planning or design of server virtualization infrastructure. Rather, it addresses planning and design of the VMM infrastructure that is used to manage a server virtualization environment. For guidance about planning and designing virtualization infrastructure, see the Infrastructure Planning and Design Guide for Windows Server Virtualization at http://www.microsoft.com/ipd.
  • Planning Operations Manager infrastructures. Although this guide discusses integrating Virtual Machine Manager and Operations Manager, it does not discuss planning or designing an Operations Manager infrastructure. For guidance, see the Infrastructure Planning and Design Guide for System Center Operations Manager 2007 at http://www.microsoft.com/ipd.

Step 1: Define the Project Scope

In this step, the project team should determine which parts of the organization to include in the design. The team should also align technical decisions with business objectives and make appropriate trade-offs between feature usage, fault tolerance, capacity, and performance. Therefore, clearly defining the scope of the project is important. The team will use the information it collects in this step to drive decisions in subsequent tasks.

This step identifies the organization's functional requirements. This information in turn enables the creation of a design that meets business requirements. In this step, the project team makes the following determinations:

  • Present and future locations in scope for the project
  • Characteristics of each location that's in scope for the project
  • Requirements for supporting self-service provisioning of VMs
  • Management model (central or local) for the project

This step drives technical decisions that the project team will make in subsequent steps. The outputs of this step are a detailed list of locations in scope for VMM, self-servicing requirements, and management requirements. The team will use the information it collects in this step to determine the number of VMM instances in Step 4, size and place VMM and Web servers in Step 5, size and place library servers in Step 6, and design network connections in Step 7.

Task 1: Identify Locations to Manage

The project team can choose to deploy VMM to manage VM hosts across all or part of the organization. Alternatively, the team may choose to deploy the entire VMM server infrastructure on a single server to an individual department. The team uses the choices it makes in this task to determine the size and placement of VMM servers and library servers in Steps 5 through 7.

Record the following information in Appendix A: "Project Scope Job Aid":

  • How much of the organization is in scope. Determine the scope of the project team's responsibility. Is the team responsible for deploying VMM throughout the entire organization or just a portion of it? Record the project scope in Table A-1 "Project Scope" and list the chosen locations in Table A-2 "Location Inventory" in Appendix A.

After completing this task, the project team has a list of specific locations in which to deploy VMM. The team carries forward the information it collected in this task to Task 2.

Task 2: Assess Each Host Location

To further categorize the locations that the project team identified in task 1, the team should identify the virtualization technologies each location uses. The team should also identify any VM management technology and systems management technology that each location uses to manage virtualization.

Record the following information in Table A-2 in Appendix A:

  • Identify the virtualization technology each location uses, if any. VMM can manage hosts running Virtual Server 2005 on Windows Server 2003 or Windows Server 2008, Hyper-V on Windows Server 2008, and VMware ESX through VMware VirtualCenter. In Table A-2 in Appendix A, indicate which virtualization technology each location uses. For more information about planning a virtualization infrastructure, see the Infrastructure Planning and Design Guide for Windows Server Virtualization at http://www.microsoft.com/ipd.
  • Identify the VM management technology each location uses, if any. The most common pre-existing VM management technologies include Virtual Machine Manager 2007 and VMware VirtualCenter. In Table A-2 in Appendix A, identify the VM management technologies, if any, that each location uses to manage hosts and VMs. The project team uses this information to determine whether a VMM upgrade is possible and to design network connections in Step 7.
  • Identify the number of hosts at each location, if any. When sizing and placing VMM instances in Steps 4 and 5, the project team should know how many hosts are at each location. Record the number of existing and planned hosts for each location in Table A-2 in Appendix A.

The project team has created an assessment in Appendix A of each location to which it is deploying VMM. The team will use the assessment it created in this task to size and place VMM instances, Web servers, and library servers in the organization. After completing this task, the team can move to task 3.

Task 3: Determine If Self-Service Provisioning Is a Business Requirement

VMM supports self-service provisioning of VMs to hosts. Administrators can allow delegated users to provision VMs by using a Web portal. Determining whether the business requires support for self-service provisioning and which locations should support this capability will affect how the team sizes and places Web servers in Step 5.

Record the following information in Tables A-1 and A-2 in Appendix A:

  • Determine whether the business requires support for self-servicing. Ask business stakeholders whether the solution must support self-service provisioning. This is a necessary prerequisite for performing this task. If the business has no requirement to use self-service provisioning, the team can move on to task 4.
  • Determine the locations at which the business requires self-service provisioning. Determine which in-scope locations must support self-service provisioning. The project team uses this information to plan the sizing and placement of Web servers in Step 5.
  • For each self-service location, determine the location of delegated self-service users. In addition to determining which locations will support self-service provisioning, the project team should also determine where the location's delegated self-service users are in the organization. Are these users at the same physical location? A different location? Determining the location of delegated self-service users helps the team place Web servers in Step 5 and size network connections in Step 7.

After completing this task, the project team will understand whether the business requires self-service provisioning and for which locations.

Task 4: Identify Management Requirements

The project team may choose to align the VMM implementation with the organization's existing management model. Determining how the organization will manage VM hosts influences where the project team places VMM instances and how the team designs network connections.

For each location that the team identified in Task 1, record the following information in Appendix A:

  • Identify the organization's management model for virtualization. Examine the organization's current and planned practices for management of the virtualization environment. Identify whether a centralized management approach will be used or whether management responsibilities will be distributed, or delegated, across the organization.

    Record this information in Table A-1 in Appendix A. It will be used in Step 4 to determine the number of VMM instances that best support the organization's management model.

  • Identify whether there are plans to use server virtualization as a disaster recovery solution. Examine the organization's disaster recovery plans to understand whether server virtualization may be used to provide rapid recovery from a disaster. Record this information in Table A-1 in Appendix A. It will be used to determine the number of VMM instances in Step 4 and, for each instance, to determine the number and locations of library servers in Step 6.

Step Summary

Aligning technical decisions with business requirements is important to project success. Failure to clearly identify functional requirements that align with the business often results in a design that does not meet business needs.

In this step, the project team collected the following requirements:

  • Present and future locations in scope for the project
  • Characteristics of each location that's in scope for the project
  • Requirements for supporting self-service provisioning of VMs
  • Management requirements for the project

These requirements drive technical decisions in subsequent steps. The outputs of this step include a detailed list of locations in scope for VMM, self-servicing requirements, and management requirements. The team will use the information it collects in this step to determine the number of VMM instances in Step 4, size and place VMM and Web servers in Step 5, size and place library servers in Step 6, and design network connections in Step 7.

Additional Reading

  • Planning a Virtual Machine Manager 2007 Deployment: http://technet.microsoft.com/en-us/library/bb740910.aspx
  • Infrastructure Planning and Design Guide for Windows Server Virtualization: http://www.microsoft.com/ipd

Step 2: Determine Whether to Integrate with Operations Manager for Reporting

VMM includes an intelligent placement capability that makes recommendations on where to run each VM. It can even be used to dynamically move a VM from one VM host to another (for example, if the host resources are becoming overcommitted). The intelligent placement decisions are based on VMM's knowledge of the VM host and its current load from running VM guests. That knowledge is delivered by performance data that the VMM agent collects on the VM host. The data is sent from the VMM agent to the VMM server every 9 minutes, and the VMM server stores it in the VMM database.

Operations Manager 2007 agents may be installed on the VM host, and also in each VM guest that is running on the VM host, to provide additional complementary performance data to the VMM operator. When the Operations Manager Server Virtualization Management Pack is deployed, this data can include:

  • Monitoring the health and availability of all Virtual Machine Manager components.
  • Providing detailed monitoring of hosts and their VMs.

If the Operations Manager data is integrated into the VMM console, the VMM console user can seamlessly drill down from performance views of the VM host machine to examine performance data for each VM guest that is running on the host. They can then drill down further to view performance counters for the operating system and applications running in the VM guest.

In order to display the views containing Operations Manager data, the VMM console connects to Operations Manager as a reporting user. Operations Manager data is not stored in the VMM database.

If the Operations Manager reporting data is not integrated into the VMM console, it can still be made available to the user in a separate Operations Manager console, running on the same workstation.

The goal of this step is to determine whether to integrate historical reporting from Operations Manager into the VMM console. The step should be repeated for each VM host that will be managed by VMM. The project team should make this decision early because, if performed, this integration may affect the number of VMM instances the team defines in Step 4.

Record the decision made in this step in Appendix B: "Operations Manager Integration Job Aid." If the team chooses to integrate Virtual Machine Manager and Operations Manager, continue to Step 3 to design Operations Manager integration. If the team chooses not to integrate, or if the organization does not use Operations Manager, skip Step 3 and proceed directly to Step 4.

Option 1: Yes

Businesses that use Operations Manager can take advantage of the seamless drill down in reporting data that console integration provides. The integration also enables them to more easily leverage Operations Manager's historical reporting data to complement VM placement recommendations since the data is available in the same VMM console, under a single sign-on.

The integration itself will require some administrative work to be completed in both Operations Manager and VMM. It may also require that more VMM instances be added to the design.

If the project team chooses to integrate Virtual Machine Manager and Operations Manager, the team continues with Step 3, which guides the project team through the process of choosing between the two design options available for Operations Manager integration. Document the team's choice in Table B-1 "Virtual Machine Manager and Operations Manager Integration Information" in Appendix B before moving to Step 4.

Option 2: No

If the organization does not use Operations Manager or if the project team determined that it is not integrating Virtual Machine Manager with Operations Manager, it can move forward to Step 4 to determine the number of VMM instances the organization requires.

If the project team chooses not to integrate Virtual Machine Manager with Operations Manager, users can still take advantage of the performance data that Operations Manager provides. However, instead of using the VMM console to view this data, the Operations Manager console must also be installed and used. The result of no integration is that users must rely on two consoles instead of one.

Evaluating the Characteristics

Technical criteria are not the only factors that the project team should consider when making infrastructure decisions. The team should also map decisions to appropriate operational criteria or characteristics. The following tables compare each option for characteristics that are applicable to this decision-making topic.

Cost

Justification

Rating

Option 1: Yes

Integrating Virtual Machine Manager with Operations Manager can increase the time and effort required for the project. This is because additional VMM instances may need to be created, or Operations Manager agents may need to be multi-homed.

Medium

Option 2: No

Not integrating Virtual Machine Manager with Operations Manager adds no additional cost.

Low

Complexity

Justification

Rating

Option 1: Yes

Integrating Virtual Machine Manager with Operations Manager can increase the complexity required to maintain multiple VMM instances or multi-homing Operations Manager agents.

High

Option 2: No

Not integrating Virtual Machine Manager with Operations Manager adds no additional complexity.

Low

Validating with the Business

If Operations Manager data is not integrated into the VMM console and if users are required to use two separate consoles, each VMM operator will need separate authorization to view the Operations Manager data.

An evaluation of the cost and complexity of integrating VMM with Operations Manager should be reviewed with the business stakeholders and the people responsible for Operations Manager to see if the integration is warranted.

Step Summary

Integrating Virtual Machine Manager and Operations Manager enables users to easily take advantage of the performance statistics in the Operations Manager database. Administrators can more easily use this richer data to enable accurate VM placement and to troubleshoot performance issues.

After completing this step, the project team has decided whether to integrate Virtual Machine Manager and Operations Manager and recorded this decision in Appendix B. If the team decided to integrate both System Center products, continue with Step 3 to design the integration. If the team decided not to integrate the products or if the organization does not use Operations Manager, continue to Step 4.

Additional Reading

  • System Center Operations Manager home page: http://www.microsoft.com/systemcenter/opsmgr/default.mspx
  • System Center Virtual Machine Manager home page: http://www.microsoft.com/systemcenter/scvmm/default.mspx
  • Infrastructure Planning and Design Guide for System Center Operations Manager 2007: http://www.microsoft.com/ipd

Step 3: Design Operations Manager Integration

Operations Manager reports can be viewed directly in the VMM console if these two products are integrated. The integration smoothes the operator's logon experience and enables seamless drill down into an individual VM's performance data when troubleshooting a problem.

In order to deliver integrated reporting, VMM uses the Operations Manager Connector Framework to connect to a management group. The scope of the reporting data available from that connection is limited to VM hosts within that management group. Therefore, if more than one management group contains a VM host, the project team has two options for delivering integrated reporting on those VM hosts:

  1. Design at least one VMM instance for each Operations Manager management group that contains VM hosts. In this scenario, the organization will maintain multiple VMM instances. The section, "Option 1: Multiple Virtual Machine Manager Instances," describes this option.
  2. Dedicate an Operations Manager management group to VMM and multi-home the Operations Manager agents that are on VM hosts. In this scenario, the organization will maintain the additional management group with its associated reporting database. The section, "Option 2: Dedicated Management Group for VMM," describes this option.

The project team should complete this step if it chose in Step 2 to integrate Virtual Machine Manager with Operations Manager. The step must be completed for each location. The design decision that the team makes in this step affects the number of VMM instances the team defines in Step 4. This decision can also affect the number of management groups that project teams define when using the guidance in the Infrastructure Planning and Design Guide for System Center Operations Manager 2007 at http://www.microsoft.com/ipd.

Record the design decision in Table B-1 in Appendix B. After completing this step, continue to Step 4 to determine the number of VMM instances the team requires.

Note   This step assumes the organization is planning to deploy or has already deployed Operations Manager. For more information, see the Infrastructure Planning and Design Guide for System Center Operations Manager 2007 at http://www.microsoft.com/ipd.

Option 1: Multiple Virtual Machine Manager Instances

This option requires that the team designs a separate VMM instance for each management group that contains VM hosts. The VMM server in each VMM instance will be connected to the root management server (RMS) of the Operations Manager management group, as shown in Figure 4.

Figure 4. One Virtual Machine Manager instance is designed for each Operations Manager management group.

If the project team chooses this option, determine which management groups will contain VM hosts that are within the project's scope. Record the decision and list the management groups in Table B-2 "Management Groups Containing Hosts" in Appendix B. The team will use this information to design the number of VMM instances in Step 4 and to design and place VMM servers in Step 5.

Benefits

This option works within the organization of the existing management groups.

Challenges

  • Must deploy additional VMM instances, each with a server, database, and library server.
  • Makes placing and sizing VMM servers more complex.
  • Prevents the organization from consolidating management of VMs.

Option 2: Dedicated Management Group for VMM

The Operations Manager agent can be configured to multi-home so that it simultaneously sends event, alert, and performance data to more than one management group. In order to complete this work, the VMM design project team must work with the Operations Manager design team to define a new management group that will be dedicated to integration with VMM. The Operations Manager agents that are running on VM hosts are then configured to multi-home so that they provide performance data to both their regular management group and to the management group that is connected to VMM.

If the project team chooses this option, for each new Operations Manager management group that will be designed, record the following in Table B-1, and share the information with the Operations Manager design team:

  • The management group name
  • The names of the Operations Manager agents that will be multi-homed to the management group

The team will design the number of VMM instances in Step 4 and place VMM servers in Step 5 based on this decision. Additionally, the team should communicate this decision to the team responsible for planning and designing Operations Manager. For more information, see the Infrastructure Planning and Design Guide for System Center Operations Manager 2007 at http://www.microsoft.com/ipd.

Benefits

  • Simplifies deployment by using fewer VMM servers.
  • Simplifies placing and sizing of VMM servers.
  • Enables the organization to consolidate VM management.

Challenges

  • Requires the addition of a new Operations Manager management group and its associated infrastructure.

Evaluating the Characteristics

Technical criteria are not the only factors that the project team should consider when making infrastructure decisions. The team should also map decisions to appropriate operational criteria or characteristics. The following tables compare each option for characteristics that are applicable to this decision-making topic.

Complexity

Justification

Rating

Multiple instances

The organization must manage multiple VMM servers.

High

Dedicated management group

The organization can manage as few as one VMM server and centralize management.

Low

Cost

Justification

Rating

Multiple instances

The organization must deploy and manage multiple VMM servers.

High

Dedicated management group

The organization can deploy and manage as few as one VMM server.

High

Step Summary

Integrating Virtual Machine Manager with Operations Manager enables users to seamlessly view Operations Manager reports in the VMM console. However, each VMM instance can display reporting data from only one Operations Manager management group. So if the VM hosts that are to be managed exist in more than one management group, the architect must choose whether to design additional VMM instances or to multi-home the Operations Manager agents that are on the VM hosts to an additional VMM-connected management group.

After completing this step, the project team has chosen a design option for Virtual Machine Manager and Operations Manager integration and recorded this decision in Appendix B.

The team uses this decision in three ways:

  • To determine the number of VMM instances in Step 4.
  • To determine VMM server placement in Step 5.
  • To communicate requirements to the team responsible for planning the Operations Manager infrastructure.

After completing this step, the team proceeds to Step 4 to design the number of VMM instances.

Additional Reading

  • Server Virtualization Management Pack. Available as a Management Pack from the System Center Operations Manager 2007 Catalog: http://go.microsoft.com/fwlink/?LinkId=86411
  • Planning for Monitoring and Reporting: http://technet.microsoft.com/en-us/library/bb740907.aspx
  • Infrastructure Planning and Design Guide for System Center Operations Manager 2007: http://www.microsoft.com/ipd

Step 4: Determine the Number of Virtual Machine Manager Instances Required

The goal of this step is to determine the number of VMM instances the organization requires. Both business and technical requirements drive this determination.

This guide defines a VMM instance as a VMM server connected to a unique VMM database instance. The organization must install each VMM server on a separate computer (physical or virtual), and each must have a separate database instance. However, multiple VMM servers can share the same database server. While completing this step, consider the following:

  • The organization can manage each VM host by using only one VMM instance. In other words, VM hosts cannot connect to multiple VMM instances.
  • VMM instances do not integrate and do not share data. There is no relationship between separate instances.

Figure 5 illustrates the process for determining the number of instances to design.

Figure 5. The process to determine the number of VMM instances that are required

During Step 1, the project team recorded VMM business requirements in Appendix A. During Step 3, it also recorded Operations Manager design requirements in Appendix B. The team will use those requirements to complete this step. For example, a decentralized management model might require more instances than a centralized management model. In addition, choosing in Step 3 to organize VM hosts in multiple Operations Manager management groups will also require more instances of VMM.

This step determines the number of VMM instances the organization requires. Record each instance in Appendix C: "Virtual Machine Manager Instances Job Aid." The project team will use this information in Step 5 to size and place VMM servers, database servers, databases, and Web servers.

Task 1: Determine Required Instances

The organization should plan to deploy at least one instance of VMM. Starting with a single instance enables the organization to scale out by adding more VM hosts and library servers. Also, having a single instance with a single database enables the organization to centrally manage the entire virtual environment.

In some cases, however, deploying multiple instances can be useful. When defining multiple instances, the project team should consider that separate instances do not integrate and do not share data. Therefore, every additional instance decentralizes the virtualization management. So begin with one VMM instance to manage all the VM hosts, and add more VMM instances if any of the following apply:

  • Isolated networks. The project team recorded each location containing in-scope VM hosts during Step 1 in Appendix A. Determine which of these networks are isolated and therefore require a separate VMM instance. For example, organizations often isolate lab networks from production networks and require a separate instance of VMM for each. Record this information in Table C-1 "Virtual Machine Manager Instance Information," and then list the location of each isolated network that requires a new instance in Table C-2 "Virtual Machine Manager Instance Location Information" in Appendix C.
  • Self-service provisioning. During Step 1, the project team determined the locations requiring self-service provisioning and recorded this in Appendix A. If the organization has chosen to separate self-service hosts and VMs from secure hosts and VMs, the team may decide to define a new instance for self-service provisioning. Additionally, if there will be a population of more than 1,000 VMs dedicated for use by self-service users, the VMM product group suggests deploying a separate VMM instance for them. Before doing this, examine the workflow of the self-service users to understand whether they typically place a different load on the VMM server infrastructure than non self-service users. If the workflow and behaviors of the users are the same, there may be no need for a separate instance.

    Determine whether any of the locations require separate instances for self-service provisioning, and record this in Table C-1. Record each separate self-service instance in Table C-2.

  • Number of Operations Manager management groups. During Step 3, in Appendix B, the project team documented its design decisions for Virtual Machine Manager and Operations Manager integration. Each of the Operations Manager management groups that will be integrated with VMM requires a separate instance of VMM. Record each additional instance in Table C-2 in Appendix C.
  • Management model: local or centralized. During Step 1, the project team recorded in Appendix A the organization's management model and each location containing in-scope VM hosts. If the organization uses a local management model, define a new instance for each location that has in-scope VM hosts, which enables each location to manage its own virtualization environment. If the organization uses a centralized management model, choose the location that will host the centralized instance. Record each instance and its location Table C-2 in Appendix C.
  • Organizational considerations. Determine if organizational or political considerations require new VMM instances, and record them under the "Reason" column in Table C-2 in Appendix C. For example, if two business units have their own IT departments, define a VMM instance for each business unit.
  • Disaster recovery. Once the above criteria have been used to design the number of VMM instances, examine the organization's disaster recovery strategy and its relationship to the virtualization environment. If virtualization will be used as part of a disaster recovery strategy, additional instances of VMM may need to be planned in order to support that.
  • Number of VM hosts in the project's scope. During Step 1, the project team identified the number of in-scope VM hosts and documented this in Appendix A. Each VMM instance supports up to 400 VM hosts and 8,000 VMs. Environments containing more hosts or VMs must define multiple instances to remain within the supported limits of each instance.

For each instance the project team adds to Appendix C, record the number of hosts the VMM instance will manage in Table C-2. The team can use the number of hosts it recorded in Appendix A during Step 1 to determine the number of hosts each VMM instance will manage. The team uses this information during Step 5 to size each server according to the number of hosts it will manage.

Step Summary

An instance is a VMM server connected to a unique VMM database. Although a single VMM instance is the best practice, some organizations benefit from multiple VMM instances. For example, the project team can define one instance for a lab environment and another instance for the production environment.

After completing this step, the project team has determined the number of VMM instances the organization requires and which instances will share a database server. The project team recorded these decisions and information about each instance in Appendix C. The project team continues with Step 5 during which it uses the information gathered in this step to size and place VMM servers, database servers, databases, and Web servers for each instance.

Additional Reading

  • System Center Virtual Machine Manager home page: http://www.microsoft.com/systemcenter/scvmm/default.mspx
  • Supported Configurations: http://technet.microsoft.com/en-us/library/bb963738.aspx

Step 5: Size and Place the Virtual Machine Manager Server, SQL Server-Based Server, Database, and Web Server

The goal of this step is to design the servers for each VMM instance that the project team identified in Step 4. Design characteristics include each server's form factor, size, physical placement and, where necessary, the fault-tolerance strategy.

Determining appropriate size, placement, and distribution of server roles is an important element in delivering the required monitoring functionality at a level of performance and fault tolerance that the organization expects.

The team completes the following tasks for each VMM instance:

  • Design the VMM server.
  • Design the database server. Multiple VMM instances can share a single database server, so this includes deciding whether to share or dedicate servers running Microsoft SQL Server®.
  • Design Web servers for each VMM instance on which the organization will enable the self-service portal.

The VMM server roles can be run together on a single machine, or they can be separated onto different machines. Each role can be run in a VM.

After completing this step, the project team has a list of server requirements, which the team records in Appendix D: "Server Size and Placement Job Aid." The team will use this information in Step 6 when sizing and placing library servers and in Step 7 to design network connections between servers and VM host locations.

Planning Limitations

Ideally, the architectural design of the server roles would be based on the following information about each role:

  • Integration (where this role fits relative to other roles)
  • Capacity requirements
  • Performance characteristics
  • Unit sizing and volume expectations for data being sent and received by the role

    As of this writing, detailed data on capacity, performance, and sizing for Virtual Machine Manager 2008 is not available.

    Simulation of the load on the server environment from the expected number of VMM agents might be another way to approach this, but there are no such load simulators available.

    Supported hardware configurations are published by the SCVMM product group at http://technet.microsoft.com/en-us/scvmm/default.aspx. These configurations are based on the number of VM hosts that the VMM instance will manage.

    Task 1: Design the Virtual Machine Manager Server

    The VMM server defines a VMM instance and is the connecting hub for the components in an instance. It performs the following functions:

    • Reads the configuration of the instance from the VMM database at startup and writes configuration changes to that database.
    • Communicates with VMM agents that are running on the VMM database, the VMM library server, and VM hosts.
    • Manages physical-to-virtual (P2V) conversions that run on connected servers.
    • Manages VM provisioning onto connected VM hosts. The VM image does not pass through the VMM server; rather it is transferred directly from the VMM library server to the VM host.
    • Receives performance data from each of the VM hosts and writes that data to the VMM database. This data is transferred once every 9 minutes.
    • Performs intelligent placement calculations upon user demand to recommend which host a VM should run on.
    • Sends configuration and performance data to the VMM console for display.
    • Sends configuration and performance data to the VMM Web server for display on the Web console.
    • Optionally, requests and receives performance data from Operations Manager, which it then sends to the VMM console for display. Operations Manager data is not written to the VMM database.

    These tasks place a relatively light workload on the VMM server, and that is reflected in the product group recommendations, referenced above. At the time of writing, the maximum recommended hardware configuration, which is supported to manage 8,000 VMs on 400 VM hosts, is a dual processor, dual core machine with 8 GB of RAM.

    Additional considerations for designing each VMM server are:

    • Physical placement. Each instance that is on an isolated network will require a separate VMM server placed on that network. Referring to the functions that the server performs, listed above, the volume of network traffic that flows to and from the server is relatively small, so there should be no other requirement to co-locate VMM servers with the VM hosts that they manage. Therefore, in the absence of other requirements, the server should be located centrally in a secure IT location where it can be most easily maintained.
    • Fault tolerance. The VMM server is stateless; the state of the VMM instance is held in the VMM database. The VMM server does not support any fault-tolerance options. If a VMM server fails, the organization can replace it with a new server without any data loss. And if the VMM server is run in a VM, a replacement VM could quickly be brought up to replace it on the same VM host or on a different VM host.

    Decide what the VMM server form factor will be, and then document the applicable information in Table D- 2 in Appendix D. The project team uses this information in the ensuing tasks to size and place the database and Web servers.

    Task 2: Design the Database Server and Database

    The VMM database stores the configuration and performance for the instance. Unlike the VMM server, it is stateful. The database and its database server perform the following functions:

    • Stores the configuration of the instance. Sends this information to the VMM server at startup and receives configuration change information from the VMM server during operation.
    • Receives performance data from the VMM server for each of the VM hosts and writes that data to the VMM database once every 9 minutes. This data is recorded as a set of rolling averages; each average is updated every 9 minutes. So after the first record has been written, it is only updated; it does not grow any larger.
    • Delivers VM host performance data to the VMM server so that it can perform intelligent placement calculations, upon user demand, to recommend which host a VM should run on.

    These tasks place a relatively light workload on the database server, and this is reflected in the product group recommendations, referenced above. At the time of writing, the maximum recommended hardware configuration, which is supported to manage 8,000 VMs on 400 VM hosts, is a dual core machine with 8 GB of RAM and 200 GB of available disk space.

    Additional considerations for designing each database server are:

    • Physical placement. The project team generally determined the placement of each VMM database server when placing VMM servers in the previous task. The team should place the database servers at the same physical location as the VMM server. Where a database server is shared between VMM instances, aim to place it in the same location as the VMM servers.
    • Fault tolerance. The VMM database server can be made fault tolerant if this requirement was identified in Step 1. The project team can design the database server to use failover clustering. For more information about designing high availability database solutions, see "High Availability Solutions Overview" at http://technet.microsoft.com/en-us/library/ms190202.aspx.

    VMM instances cannot share a database. However, VMM instances can share database servers.

    Decide what the VMM database server form factor will be, and then document the applicable information in Appendix D: "Server Size and Placement Job Aid."

    Record the configuration and placement of each VMM database server in Table D-1: "Virtual Machine Manager Server Instance Configuration and Placement Information" in Appendix D. After completing this task, continue with Task 3.

    Task 3: Design the Web Server

    VMM provides a self-service portal that allows users to provision VMs to VM hosts without administrator intervention. The project team determined the requirement for self-service provisioning during Step 1 and recorded that decision in Appendix A for each location. If the VMM instance will support self-service provisioning, the team should size and place the Web server in this step. If not, skip this step.

    The VMM Web server is used to communicate between the VMM server and Web portal users. It performs the following functions:

    • Receives display requests from the Web consoles.
    • Sends configuration and performance data to the Web consoles for display.

    The self-service portal requires a Microsoft Internet Information Services (IIS) server. For more information about planning and designing an IIS infrastructure, see the Infrastructure Planning and Design Guide for Internet Information Services 7.0 at http://www.microsoft.com/ipd.

    The workload demand on the VMM Web server suggests that it is a relatively lightweight application, and indeed the maximum recommended IIS server configuration is a dual core machine with 2 GB of RAM. Given this, the VMM Web server application should be integrated with the organization's strategy for IIS server deployment and placement.

    Decide what the VMM Web server form factor will be, and then document the applicable information in Table D-1 in Appendix D.

    After completing this task, repeat Step 5 for the remaining VMM instances. After sizing and placing the servers for the last VMM instance, the team is finished with this step and is ready to continue to Step 6.

    Step Summary

    After completing this step, the project team has designed the server environment, including the VMM server, the database server and database, and the Web console server, if required. The design, which the team recorded in Appendix D, includes each server's form factor, fault tolerance, size, and physical placement.

    The team completed the following tasks for each instance in the list:

    • Designed the server for each VMM instance.
    • Designed the database server and database for each VMM instance. Multiple VMM instances can share a single database server.
    • Designed each Web server for each VMM instance that the organization allows self-service provisioning.

    The team will use this information in Step 6 when sizing and placing library servers.

    The team will also use this information in Step 7 to design network connections between servers and locations. After completing this step, proceed to Step 6.

    Additional Reading

    • System Center Virtual Machine Manager home page: http://www.microsoft.com/systemcenter/scvmm/default.mspx
    • Virtual Machine Manager System Requirements: http://technet.microsoft.com/en-us/library/bb740949.aspx
    • System Center Virtual Machine Manager 2007: Planning, Installing, and Configuring: http://technet.microsoft.com/en-us/library/bb740743.aspx

    Step 6: Size and Place the Library Servers and Libraries

    The Virtual Machine Manager library is a set of resources that can be used to create and configure VMs. Libraries can include the following:

    • Virtual Hard Drive (VHD) and Virtual Machine Configuration (VMC) files
    • VM templates and guest operating system profiles
    • Scripts and Sysprep answer files
    • ISO image files
    • Virtual floppy disks

    The VMM library server is a file server with one or more shares. A VMM agent runs on the file server; which defines it as a VMM library server and provides communication with the VMM server that defines the VMM instance. Only one VMM agent can be run on each library server, so the library server can connect to only one VMM server. But a VMM server can be connected to more than one library server. This is shown in Figure 6.

    Figure 6. The Virtual Machine Manager library server and its library shares

    The VMM library server performs the following functions:

    • Stores the files listed above.
    • Sends the files to the VM hosts where they will be instantiated as running VMs.

    The images that are stored in the library can be very large, and when they are transferred to a VM host during virtual machine creation, a significant traffic load is created on the network. For this reason, the VMM product group strongly recommends that library servers be placed in the same location as the VM hosts that they will service.

    Each VMM instance must have at least one library server, and VMM instances cannot share library servers because each library server runs a VMM agent.

    This step's goal is to design the library servers for each instance the project team identified in Step 4. The step should be repeated for each library server.

    Design characteristics determined during this step include each library server's form factor, fault tolerance, replication, size, and physical placement. The team completes the following tasks and actions for each VMM instance in the list:

    • Design and place the library server for each VMM instance.
    • Determine the method to use to provide fault tolerance for library shares.

    After completing this step, the project team will have a list of library servers, their requirements, and their placement, which the team records in Appendix E: "Library Server Size and Placement Job Aid." The team will also use this information in Step 7 to design network connections between VMM servers, library servers, and locations containing VM hosts.

    Task 1: Design and Place the Virtual Machine Manager Library Server

    In this task, the project team designs each VMM library server and determines its physical placement.

    The library server acts as a storage depot for the VMM instance. It writes image files into storage and then retrieves them on demand in order to create VMs. The supported hardware configuration for the library server is published by the VMM product group at http://technet.microsoft.com/en-us/scvmm/default.aspx. At the time of writing, a dual core machine with 2 GB of RAM is recommended. The storage configuration will vary depending on the number and size of the following files that will be stored in the library. Use Table E-1 "Virtual Machine Manager Library Server Configuration and Placement Information" in Appendix E to record the contents of each library, and sum them to calculate its expected size.

    VMM supports all forms of direct attached storage (DAS) and supports Fibre Channel or an iSCSI storage area network (SAN). For more information about using DAS or SAN storage with VMM, see "Storage Considerations" at http://technet.microsoft.com/en-us/library/bb963723.aspx.

    Decide what the VMM library server's form factor will be, and then document the applicable information in Table E-1 in Appendix E: ""Library Server Size and Placement Job Aid."If a VMM instance requires more than one library server, record each server separately.

    Decision 1: Design Fault Tolerance

    In order to increase the availability of the VMM library, the project team can make the library share fault tolerant. In this decision, the team determines a method for making the library share of each VMM library server fault tolerant. This decision process must be repeated for each library server. If the team determines in Step 1 that fault tolerance is not a requirement, skip this decision and continue to the next step.

    Option 1: Distributed File System

    The organization can use Distributed File System (DFS) namespace to provide fault-tolerant access to library shares. DFS allows administrators to define a file namespace and provide multiple targets for folders contained within the namespace. When a host accesses a DFS-enabled share, the nearest DFS server hosting that share handles the request. If that library share becomes unavailable, the library can still transfer files from another replica share in the namespace.

    If the project team chooses to use DFS to provide fault tolerance, record the decision in Table E-1 in Appendix E. Also record the location of the library share and the library servers that will connect to it. Then, continue with the next decision.

    Further guidance on planning a DFS namespace is available in Infrastructure Planning and Design Guide for File Services at www.microsoft.com/ipd.

    Option 2: Server Clustering

    Server clustering can increase the fault tolerance of a single VMM library share. The library share is defined as a clustered resource running on a cluster with two or more library servers. If the server hosting the library share fails, the library share moves to a remaining active node.

    If the project team chooses to use server clustering to provide fault tolerance, record the decision in Table E-1 in Appendix E. Then, continue with the next decision.

    Note   Server clustering cannot be used to provide fault tolerance when the library share is on a server that is also the VMM server. VMM is not cluster-aware; therefore, it doesn't support server clustering.

    Evaluating the Characteristics

    Complexity

    Justification

    Rating

    DFS

    Configuring the DFS namespace can be moderately difficult. Microsoft provides guidance for implementing this form of file protection using DFS.

    Medium

    Server clustering

    Server clustering tends to be extremely complex to set up due to the interaction between networks, shared storage, and specialized hardware and software configurations.

    High

    Cost

    Justification

    Rating

    DFS

    If using existing file servers, then DFS is fairly low in cost as it is built into the operating system.

    Low

    Server clustering

    Server clustering is costly due to the requirements of additional servers and shared storage.

    High

    Scalability

    Justification

    Rating

    DFS

    DFS allows for multiple copies of the library share to be accessible at the same time through a single namespace.

    Server clustering

    The cluster allows only one copy of the library share to be accessible through a single namespace on the cluster.

    Validating with the Business

    How important is it to the organization to have Virtual Machine Manager library servers always available? Is VMM considered important enough to ensure the fault tolerance of the system? The cost of putting fault tolerance in place may outweigh the benefit.

    Step Summary

    After completing this step, the project team has a list of library servers and their requirements, which the team recorded in Table E-1 in Appendix E. These requirements include each library server's form factor, fault tolerance, replication, size, and physical placement.

    The team completed the following tasks for each VMM instance to determine each library server's requirements:

    • Designed and placed the library server for each VMM instance.
    • Determined the method to use to provide fault tolerance for library shares.

    The team will also use this information in Step 7 to design network connections between VMM servers, library servers, and locations containing VM hosts. After completing this step, proceed to Step 7.

    Additional Reading

    • System Center Virtual Machine Manager home page: http://www.microsoft.com/systemcenter/scvmm/default.mspx
    • Virtual Machine Manager System Requirements: http://technet.microsoft.com/en-us/library/bb740949.aspx
    • System Center Virtual Machine Manager 2007: Planning, Installing, and Configuring: http://technet.microsoft.com/en-us/library/bb740743.aspx

    Step 7: Design the Network Connections

    In this step, the project team uses the following information to determine network bandwidth, including:

    • Information about the locations containing hosts that the team collected in Step 1.
    • List of required VMM instances that the team collected in Step 4.
    • The placement of VMM servers, database servers, database, and Web servers that the team determined in Step 5.
    • The placement of VMM library servers, determined in Step 6.

    The project team uses this information to determine necessary changes in network firewalls as well as any network links requiring additional network bandwidth to support VMM minimum requirements.

    Task 1: Determine Where Additional Bandwidth Is Required

    The goal of this task is to identify and record the network bandwidth required as well as the bandwidth available between each of the VMM components. Record this information in Table F-1 "Virtual Machine Manager Network Bandwidth Information" in Appendix F: "Network Design Job Aid."

    To make these determinations, perform the following steps:

  1. Use the output of Steps 5 and 6 to map the connections between each VMM server, database server, Web server, and library server. In addition, record the bandwidth requirements of each, using the Network Considerations page at http://technet.microsoft.com/en-us/library/bb963719.aspx. Record this information in Table F-1.
  2. Measure the available bandwidth on these connections. Simply request the average available bandwidth during peak usage periods. Record this information in Table F-1, and indicate whether an upgrade is required.

Step Summary

The goals of this step were to ensure that network connectivity between VMM servers and agents is sufficient in terms of network bandwidth and that required firewall rules are in place to allow traffic to flow as necessary.

In this step, the following data was used to determine network bandwidth:

  • Information about the locations containing hosts that the team collected in Step 1.
  • List of required VMM instances that the team collected in Step 4.
  • The placement of VMM servers, database servers, and Web servers, which the team determined in Step 5.
  • The placement of VMM library servers, determined in Step 6.

The output of this step is the Appendix F: "Network Design Job Aid," which contains the bandwidth requirements between physical network sites. This information is used in the implementation phase of the project to identify necessary changes in network firewalls as well as any network links requiring additional network bandwidth to support VMM.

Additional Reading

  • System Center Virtual Machine Manager home page: http://www.microsoft.com/systemcenter/scvmm/default.mspx
  • Virtual Machine Manager System Requirements: http://technet.microsoft.com/en-us/library/bb740949.aspx
  • Network Considerations: http://technet.microsoft.com/en-us/library/bb963719.aspx

Conclusion

This guide summarized the critical design decisions, activities, and tasks required to successfully design a VMM infrastructure. This guide addressed the fundamental decisions and tasks involved in:

  • Identifying the business and technical requirements for managing virtualization.
  • Determining whether to integrate Virtual Machine Manager with Operations Manager and how to design that integration.
  • Determining the number of VMM servers the organization requires, including each server's size, form factor, placement, and connectivity.

This guide described steps for creating a design based on the organization's business and technical requirements. As appropriate, this guide illustrated typical usage scenarios in the decisions and tasks. It discussed the technical aspects, characteristics, and business requirements needed to complete a comprehensive review of the decision-making process.

After planning and designing the architecture, the project team should conduct limited pilot tests before beginning a major rollout. The team can incorporate lessons learned from the pilot tests back into the design.

When used in conjunction with the VMM documentation, this guide allows organizations to confidently plan the implementation of VMM.

Appendix A: Project Scope Job Aid

Use the following job aids to record the decisions made in each step. The grey text represents sample language that illustrates how each task might be completed.

Step 1. Document the scope of the VMM project by identifying the organization's locations that are in scope and their characteristics.

Table A-1. Project Scope

Question

Answer

What are the parts of the organization for which the project team is responsible?

The project team is responsible for deploying VMM to all locations within the organization that are using virtualization technologies.

Does the organization require support for self-service provisioning?

Yes, only in locations containing development teams. This enables developers and test engineers to provision their own VMs for developing and testing their work.

What is the organization's management model?

The organization designs and plans the infrastructure centrally, but each location operates its own infrastructure while centralized IT monitors each location. Each location will manage its own virtualization technology by using VMM.

Will the organization use VMM as part of a disaster recovery solution?

No.

Table A-2. Location Inventory

Location

Existing virtualization technology

Existing VM management technology

Number of hosts

Self-service provisioning?

Location of delegated self-service users (t-4)

Dallas

Virtual Server

None

25

No

N/A

Houston

Virtual Server

None

30

No

N/A

Seattle

Virtual Server

Hyper-V

Virtual Machine Manager

15

Yes

Seattle

Appendix B: Operations Manager Integration Job Aid

Steps 2 and 3. Determine whether the organization will integrate the Virtual Machine Manager and Operations Manager consoles.

Table B-1. Virtual Machine Manager and Operations Manager Integration Information

Question

Answer

Will the organization integrate the Virtual Machine Manager and Operation Manager console?

Yes

Will the project team use multiple instances of Virtual Machine Manager to integrate with multiple management groups, or will it create a new management group and multi-home Operations Manager agents?

The organization has a management group for each physical location. The project team will create one instance of VMM server for each.

What are the new management groups called, and which Operations Manager agents will be multi-homed to them?

Management group name: VMM Alaska integration

Reporting agents: Prudhoe_Bay_1 thru Prudhoe_Bay_33

Table B-2. Management Groups Containing Hosts

Management groups containing hosts

Dallas

Houston

Seattle

Appendix C: Virtual Machine Manager Instances Job Aid

Step 4. Record each VMM instance required.

Table C-1. Virtual Machine Manager Instance Information

Question

Answer

Does the organization have more than 400 hosts?

No

What are the isolated networks that will require a new instance?

Seattle, Test Lab Network

Which locations will use a separate instance for self-service provisioning?

Seattle

Table C-2. Virtual Machine Manager Instance Location Information

Instance location

Reason

Number of hosts

Dallas

Operations Manager management group

25

Houston

Operations Manager management group

30

Seattle, Production

Network isolation, management group, self-service provisioning

5

Seattle, Self-service

Network isolation, management group, self-service provisioning

5

Seattle, Test lab network

Network isolation

5

Appendix D: Server Size and Placement Job Aid

Step 5. Record the configuration and placement of each server. Each instance requires a VMM server, a database server and, optionally, a Web server.

Table D-1. Virtual Machine Manager Server Instance Configuration and Placement Information

Instance

Virtual Machine Manager server

Database server

Web server

Dallas

Placement: At Dallas location

Configuration: Dual-processor 3.2 GHz CPU, 4 GB of RAM, 200 MB of hard disk space

Fault Tolerance: None

Placement: At Dallas location

Configuration: Dual-core 64-bit 3.2 GHz CPU, 4 GB of RAM, 150 GB of hard disk space

Fault Tolerance: Clustered SQL Server database

N/A

Houston

Placement: At Houston location

Configuration: Dual-processor 3.2 GHz CPU, 4 GB of RAM, 200 MB of hard disk space

Fault Tolerance: None

Placement: At Houston location

Configuration: Dual-core 64-bit 3.2 GHz CPU, 4 GB of RAM, 150 GB of hard disk space

Fault Tolerance: Clustered SQL Server database

N/A

Seattle, Production

Placement: At Seattle location

Configuration: Dual-processor 3.2 GHz CPU, 4 GB of RAM, 200 MB of hard disk space

Fault Tolerance: None

Placement: At Seattle location

Configuration: Dual-core 64-bit 3.2 GHz CPU, 4 GB of RAM, 150 GB of hard disk space

Fault Tolerance: Clustered SQL Server database

N/A

Seattle, Self-service

Placement: At Seattle location

Configuration: Dual-processor 3.2 GHz CPU, 4 GB of RAM, 200 MB of hard disk space

Fault Tolerance: None

Placement: In Seattle test lab

Configuration: Dual-core 64-bit 3.2 GHz CPU, 4 GB of RAM, 150 GB of hard disk space

Fault Tolerance: Clustered SQL Server database

Placement: At Seattle location

Configuration: 2.8 GHz CPU, 2 GB of RAM, 1 GB of hard disk space

Fault Tolerance: None

Seattle, Test lab network

Placement: In Seattle test lab

Configuration: Dual-processor 3.2 GHz CPU, 4 GB of RAM, 200 MB of hard disk space

Fault Tolerance: None

Placement: At Dallas location

Configuration: Dual-core 64-bit 3.2 GHz CPU, 4 GB of RAM, 150 GB of hard disk space

Fault Tolerance: Clustered SQL Server database

Placement: At Seattle location

Configuration: 2.8 GHz CPU, 2 GB of RAM, 1 GB of hard disk space

Fault Tolerance: None

Appendix E: Library Server Size and Placement Job Aid

Step 6. Record the configuration and placement of each library server.

Table E-1. Virtual Machine Manager Library Server Configuration and Placement Information

Instance

Library

Contents

Replication

Virtual Machine Manager server

Dallas

Dallas

Virtual machine templates

Virtual hard disks

DFS-R, shared with Houston

Placement: At Dallas location

Configuration: Dual-core 64-bit 3.2 GHz CPU, 2 GB of RAM, 120 MB of hard disk space

Fault Tolerance: DFS

Houston

Houston

Virtual machine templates

Virtual hard disks

DFS-R, shared with Dallas

Placement: At Houston location

Configuration: Dual-processor 3.2 GHz CPU, 4GB of RAM, 200 MB of hard disk space

Fault Tolerance: DFS

Seattle, Production

Seattle

Virtual machine templates

Virtual hard disks

None

Placement: At Seattle location

Configuration: Dual-processor 3.2 GHz CPU, 4 GB of RAM, 200 MB of hard disk space

Fault Tolerance: Server clustering

Seattle, Self-service

Seattle

Stored virtual machines

None

Placement: At Seattle location

Configuration: Dual-processor 3.2 GHz CPU, 4 GB of RAM, 200 MB of hard disk space

Fault Tolerance: Server clustering

Seattle, Test lab network

Seattle, Test lab

Virtual machine templates

Virtual hard disks

Virtual floppy disks

None

Placement: In Seattle test lab

Configuration: Dual-processor 3.2 GHz CPU, 4 GB of RAM, 200 MB of hard disk space

Fault Tolerance: Server clustering

Appendix F: Network Design Job Aid

Step 7. Record the network bandwidth.

Table F-1. Virtual Machine Manager Network Bandwidth Information

Source location

Destination location

Required bandwidth (K)

Available bandwidth (K)

Bandwidth meets requirements?

Description

Dallas

Houston

1000

1500

Yes

File replication

Houston

Dallas

1000

3000

Yes

File replication