HP Matrix Operating Environment 7.3 and 7.3 Update 1 Infrastructure Orchestration User Guide

Provisioning physical servers using local disk
Matrix infrastructure orchestration includes support for Virtual Connect logical servers using a local
disk for boot. (Local disk is also referred to as DAS, or Direct Attached Storage.) Although these
logical servers lack the flexible movement of those using boot from SAN, a logical server using
local disk boot can be initially activated on a server, have the operating system installed on the
local disk, and then later be suspended and activated on the same physical server. If the logical
server is activated on a different physical server (with a local disk of suitable size), the operating
system must be re-deployed.
In a Virtual Connect environment, the Matrix OE software automatically gathers information about
server blades (memory, processors, and potential connectivity). Local disk information is not currently
gathered, so it is necessary to annotate the collected server information to indicate if it has a local
disk with particular properties. Local disk boot volumes are not represented by storage pool entries.
You can enable Matrix infrastructure orchestration to provision to a physical server using local
disk. This involves some manual edits of property files to ensure that Matrix is aware of the servers
that have local disks and that have mobility restrictions.
See “Modifying physical servers with local disk information” in the HP Matrix Operating Environment
Logical Server Management User Guide at http://www.hp.com/go/matrixoe/docs.
Allocating servers to a VM Host
Matrix infrastructure orchestration uses the following guidelines to determine the VM Host that will
host a newly provisioned virtual machine.
Matrix infrastructure orchestration filters VM Hosts based on service template requirements, including:
• Linked clone support (if applicable)
• High availability (HA) support (if applicable)
• VM template compatibility (if specified as Automatic OS deployment)
• Sufficient number of processors
• Sufficient available memory
• Sufficient available disk space
• Network connectivity
From these candidates, infrastructure orchestration selects the VM Host that has the most:
• Available disk space
If all VM Hosts have the same amount of free disk space (which is common with cluster shared
volumes), infrastructure orchestration selects the VM Host based on processor number and available
memory.
NOTE: Matrix infrastructure orchestration does not perform load balancing in its placement of
VMs on hosts. Load balancing is performed by the hypervisor.
• All servers from a server group in an IO template must come from the same server pool. IO
does not split a single server group across multiple pools. IO will search through all available
server pools in the order that they are listed. For example, if the order of the pools is “A, B”
– and server pool A does not have capacity, then IO will continue to pool B. If there is sufficient
capacity, IO will deploy to the resources in pool B. If there is insufficient capacity from either
pool, then the request will fail. (If the IO template has two or more server groups, then IO can
place each server group in different server pools.)
• The server pool list governs where IO will target. If the server hosting the VM template is in
pool B, but pool A is listed first in the provisioning request, then IO will try to find capacity in
pool A. Only if there is insufficient capacity in pool A, will IO try pool B for capacity. Pool
order overrides the affinity to the VM template.
Matrix infrastructure orchestration lifecycle operations 119