A server pool consists of one or more Oracle VM Servers, and represents a logical grouping of the servers where a particular set of virtual machines can run. It is a requirement of all server pools that the Oracle VM Servers within them share the same CPU architecture. All servers within a server pool must be in the same physical location. Stretching server pools across geographical locations is not supported.

Oracle VM deployments can vary in design. It is equally plausible that one deployment may only use a single server pool for all of its virtualization requirements, while another deployment may consist of several server pools either catering for different hardware platforms or for complete virtual machine separation.

Server pools help to provide horizontal scalability. If you find that a server pool does not have sufficient resources, such as CPU or memory, to run the virtual machines, you can expand the server pool by adding more Oracle VM Servers. This process is discussed in Edit Server Pool in the Oracle VM Manager User's Guide. In this way, a server pool can be described as the set of resources available to a group of virtual machines.

Therefore, before creating a server pool, it is useful to consider how many Oracle VM Servers are to be included in the server pool, and which function(s) or role(s) each Oracle VM Server is to perform. See Section 6.2, “What are Server Roles?” for more information of server functions and roles. Each virtual machine running in a server pool requires resources to be available to it, such as CPU, network, and memory. You should size your server pool accordingly.

Oracle VM's usual deployment architecture utilizes server pools, with shared access to storage across Oracle VM Servers in the server pool. Virtual machines are stored on the shared storage and loaded onto any one of the Oracle VM Servers to balance the workloads of the server pool.

In a deployment that uses shared storage that is accessible to all of the Oracle VM Servers in the server pool, many other facilities are available to ensure high availability and excellent failover. A server pool can be configured as a cluster, so that virtual machines are automatically live-migrated between servers in the event of server downtime.

Since the virtual machines are not bound to any specific Oracle VM Server in the server pool, virtual machines are not prevented from starting up simply because an individual Oracle VM Server happens to be down for maintenance or otherwise unavailable at the time. Further, options are provided to specify the start policy for the virtual machines in the server pool. The start policy can implement a load-balancing algorithm that assures that a virtual machine is only started on the Oracle VM Server with the most resources available. Load balancing is achieved using the same algorithms used for Distributed Power Management (DPM) and for the Distributed Resource Scheduler (DRS). Load-balancing further helps assure the maximum aggregate performance from the server pool.

When you create a server pool in Oracle VM, you specify:

The server pool name and description are used as friendly identifiers within Oracle VM Manager to reference different server pools and to understand their purpose.

The virtual IP address is used by Oracle VM Manager to communicate with the server that is designated as the Master in the server pool. If the master changes, the virtual IP address is transferred to the new Master, ensuring that Oracle VM Manager continues to communicate with the Master server. It is possible to manually configure which Oracle VM Server is designated as the Master server in the server pool using the Oracle VM Manager Web Interface or Oracle VM Manager Command Line Interface. See Edit Server Pool in the Oracle VM Manager User's Guide for more information on setting the Master server in the server pool.

If you opt to enable clustering, the servers in the server pool are clustered and all of the configuration steps required are performed automatically through Oracle VM Manager. In this case, it is necessary for you to configure the server pool file system that is to be used to store cluster information. See Section 6.8, “How do Server Pool Clusters Work?” for more information. If you opt for a server pool without clustering, see Section 6.9, “Unclustered Server Pools”.