Operating Environment Software Instruction Manual

The virtual storage requirements that can be manually defined are as follows:
• Name of the disk.
• Individual Disk Size is the size for the disk and specifies if it is in megabytes or gigabytes. For
virtual disks, this value sets the actual size of the disk. (For virtual storage, MB x 1024 = GB.)
• Cost per GB is the estimated cost per gigabyte in numeric form.
• Disk is bootable specifies that the disk will be the boot disk for a server group.
For bootable disks, you can assign a Storage Volume Name to match mounted volume names
on a VM Host. If the Storage Volume Name is not matched, you can allocate virtual storage
manually. Any data disks configured for the logical server will inherit the names set for the
boot disk.
For non-boot disks (Disk is bootable is not checked), the Storage Volume Name field is not
enabled. The Storage Volume Name is identical to that of the boot disk.
• Disk is shared across servers specifies that the disk is a data disk (non-boot disk) and it is
shared between all of the servers in the group.
• Storage Volume Name(s) is a comma-separated list that specifies the VM Host storage volume(s)
used to allocate virtual storage for the attached server group. (This is analogous to specifying
the storage volume used to allocate storage for physical servers using Physical Storage tags.)
Storage Volume Name(s) can only be set or edited for virtual boot disks; however, the volume
names specified on the boot disk will apply to all disks attached to the server group, including
data disks.
Storage Volume Name(s) can be simple VMware ESX data store names (for example:
"ClusterStorageOne"), simple Hyper-V data store names (for example: "S") or HP-UX Shared
Logical Volume groups (for example: "/dev/slvm_disk1"). If one or more volume names are
specified, only volumes matching those names will be considered when the template is
provisioned.
Matrix infrastructure orchestration approach to storage reservation and
allocation
A key step in the service creation process involves both a reservation and an allocation phase for
all resources required by the service template. This section describes the storage reservation and
allocation rules in the storage algorithm.
The following matching rules are applied in sequential order. A rule cannot be partially matched.
For a rule to match, the entire rule definition must match. The rules give priority to finding a match
for the boot disk first.
1. Find a storage pool entry (SPE) that contains only a fully matched boot disk per the logical
server’s boot disk definition.
a. If found, find one or more additional SPEs that fully match the logical server’s data disk
definitions.
Result: If both rules 1 and 1a successfully match, provision the server(s) with the matched SPEs.
Otherwise, continue trying to find matching SPEs in different configurations.
2. If the boot disk reservation cannot be satisfied with a single SPE and independent data volume
entries, seek a single SPE that fully matches both the logical server's boot disk and private
data disk requirements. (Shared data disks must be contained in their own storage pool
entries.)
Result: If rule 2 successfully finds an SPE, provision the server(s) with the matched SPE.
3. If the boot disk reservation still cannot be satisfied, seek a single SPE that fully matches the
logical server’s boot disk definition only. (This may be the same SPE found in rule 1.)
Result: If there is a matching boot disk, skip to rule 5 to provision storage for the data disks.
Matrix infrastructure orchestration approach to storage reservation and allocation 149