System Center Virtual Machine Manager (VMM) 2007 can scale across a wide range of virtual environments from a stand-alone VMM setup on a single computer, managing a smaller virtual environment with one or more hosts, to a fully distributed enterprise environment, managing hundreds of hosts and thousands of virtual machines.
This topic presents the system requirements for the following topologies:
- All VMM components installed on a single computer.
- Each VMM component installed on a different computer.
Between the two ends of this spectrum are any number of ways that you can configure your VMM deployment to best meet your business needs and objectives.
This section provides a brief overview of the system requirements for Microsoft System Center Virtual Machine Manager (VMM) 2007 and provides links to other sections of the documentation that provide more detailed information.
The hardware requirements for VMM are presented as both the minimum and the recommended requirements. A critical factor for the successful operation of a VMM deployment is to properly configure the hardware for all VMM components, especially for virtual machine hosts. Just as with physical computers, the overall performance of a virtual machine depends significantly on the level of available resources.
The hardware and software requirements are provided for the two supported VMM deployment scenarios:
- All VMM components installed on a single computer. (https://go.microsoft.com/fwlink/?LinkId=101294)
- Each VMM component installed on a separate computer. (https://go.microsoft.com/fwlink/?LinkId=101295)
In either scenario, each virtual machine host is always a separate computer.
To view all system requirements for VMM, including virtual machine hosts, see "Virtual Machine Manager System Requirements" (https://go.microsoft.com/fwlink/?LinkId=69926).
The VMM server is the hub of a VMM deployment through which all other VMM components interact and communicate. Therefore, the VMM server must be installed first.
The VMM server communicates with the VMM database and with managed computers—virtual machine hosts and library servers. For more information about the VMM components, see About VMM Components.
Before installing the VMM server, you must join the computer to a domain in Active Directory Domain Services (AD DS). All virtual machine hosts must also be joined to domains in AD DS.
For most VMM deployments, a single VMM server is sufficient and will enable you to scale out your VMM deployment by adding more virtual machine hosts and library servers as your virtual environment grows. Having a single VMM server with a single database enables you to centrally manage your entire virtual environment.
There may be situations in which having more than one VMM server might be beneficial:
- When you want to manage your development and test virtual environment separately from your production virtual environment.
- When your virtual environment grows beyond the supported maximum number of hosts and virtual machines, which is 400 hosts and 8,000 virtual machines.
- When you have a large number of self-service virtual machines—in the range of 1,000 to 4,000 virtual machines—dedicated for use by self-service users.
If your business needs dictate that you install more than one VMM server, keep the following points in mind:
- Each VMM server must be installed on a separate computer and each VMM server must have a separate VMM database. Multiple VMM servers can use the same database server but not the same database.
- Each host or library server can be managed by only one VMM server.
- Multiple VMM environments are not integrated and cannot share data.
- VMM does not provide a method for replicating physical files in the VMM library or metadata for objects that are stored in the VMM database. Physical files must be replicated outside of VMM and metadata must be transferred by using scripts or other means.
If your environment extends beyond a central data center to include branch offices or other remote sites where you want to create, run, and manage virtual machines, there are additional topology considerations.
For branch offices, it is a best practice to deploy a VMM library server and one or more hosts at the remote site. Users in those locations can build virtual machines by using resources from a local library server instead of copying multi-gigabyte files from a centralized library server over a wide area network (WAN). This ability to use resources from a local library server can also help ensure the availability of files during WAN outages or server failures.
For a branch office topology, you might consider installing a host and a library server on the same computer. This topology is well-suited when you have 150 or less images (templates, ISOs, vhds).
Advantages of having a host and library server on one computer
- Rapid deployments. Because the files for building virtual machines are not transferred across the network, this configuration provides for quicker virtual machine deployments.
Disadvantages of having a host and library server on one computer
- Requires more overall hard disk space. Maintaining multiple copies of the same files, rather than using a single, central library server requires more hard space.
- Intelligent placement is not as advantageous with this configuration, because you usually want to use the local host because it is closest to the library server.
Supported Number of Hosts and Virtual Machines
The maximum number of hosts and virtual machines tested with and supported by VMM on the highest recommended hardware configuration is 400 hosts and 8,000 virtual machines.
If your VMM deployment is over 150 hosts, we strongly recommended that you enable server-optimized garbage collector (GC) on the VMM server instead of the default workstation garbage collector. This can significantly reduce the CPU utilization on the VMM server and improve your performance for parallel VMM operations. For more information, see the "Configuring Garbage Collection on the Server" topic on MSDN (https://go.microsoft.com/fwlink/?LinkId=102219).
The number of virtual machines that can be run on a host is primarily limited by the configuration of the host and of the virtual machines.
Support for Clusters
VMM supports virtual machine host clustering and can manage clustered virtual machines on host. If both the source and the destination host are managed by VMM, then VMM detects virtual machine changes and updates the information in the VMM Administrator Console. This is true whether the virtual machine changes hosts as the result of a clustered resource group assignment or a cluster failover.
VMM does not provide any cluster management functionality. All host clustering configuration and cluster resource group management must be performed using cluster management tools. For more information about using clusters with VMM, see the white paper "Managing Virtual Server Host Clustering with System Center Virtual Machine Manager 2007" at (https://go.microsoft.com/fwlink/?LinkId=98888).
Support for a Disjointed DNS Namespace
A disjointed DNS namespace is a Domain Name System (DNS) infrastructure that includes two or more top-level DNS domain names. For more information, see "Configuring Name Resolution for Disjointed Namespaces" at https://go.microsoft.com/fwlink/?LinkID=102322.
VMM cannot be installed in a disjointed DNS namespace.
Support for Perimeter Networks
You can manage hosts on a perimeter network, but you must install the VMM agent locally on the hosts and then add them in the VMM Administrator Console. For more information about adding a host on a perimeter network, see the "Installing a VMM Agent Locally" topic in VMM Help (https://go.microsoft.com/fwlink/?LinkId=98830).
After you deploy virtual machines on a host on a perimeter network, you cannot migrate those virtual machines back to a host on the internal network or to another host on the perimeter network.