HP Matrix Operating Environment Software - Manual (Page 92)

NOTE: Matrix infrastructure orchestration does not perform load balancing. Load balancing is
performed by the VM technology.
•
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.
To see the IP address of the VM Host where a virtual machine was provisioned, in the infrastructure
orchestration console Services tab, select the service and click Service Details. Select the server
group, and select the Resource Details tab in the lower pane. The rightmost column is labeled
Resource Binding ID, and contains the IP address of the ESX host where the VM was ultimately
created.
Allocating storage to virtual machines
Matrix infrastructure orchestration uses the following guidelines to place virtual machine disks.
•
Matrix infrastructure orchestration allocates storage to the datastore on the target VM Host
with the most free space available.
•
For each VM, the boot disk and private data disks are always allocated to the same datastore.
For Integrity VMs, a single Shared Logical Volume Manager (SLVM) datastore may be
composed of one or more physical volumes/disks. IO interprets an SLVM datastore as a single
entity, with a single size.
•
For ESX 4.0 and later, if a shared disk is defined for the server group, all disks for all the VMs
in the server group are allocated to the same datastore. (Hyper-V, Integrity VM, and ESX 3.5
do not support shared disks.)
When shared disks are specified, the first VM in the service takes longer to create than
subsequent VMs. This occurs because the first VM is created separately. After its completion,
the rest of the VMs are created in parallel.
•
If linked clone provisioning is specified (by checking Deploy as Linked Servers in the server
group configuration), all disks for all VMs in the server group are allocated to the same
datastore.
•
If a Storage Volume Name is specified in the infrastructure orchestration template, all disks
for all VMs in the server group are allocated to the datastore that matches the Storage Volume
Name.
•
If there are no shared disks, no Storage Volume Names, and no linked clones, then each VM
in the server group and its disks may be allocated to different hosts on different datastores,
or to the same host and different datastores, based on free space.
Virtual data disk names can contain letters (A-Z, a-z), numbers (0-9), space, underscore, and
hyphen. Other characters, including double-byte characters, are not allowed. Physical data disks
and boot disks can contain localized names.
92 Matrix infrastructure orchestration provisioning and allocation