10.3 The Repository Info/Groups Tab

The page that opens under the Info/Configuration tab includes several collapsible sections on the page where you can configure the general information and attributes of the repository.

NOTE:Whenever you make changes to any Grid object, the write icon is superimposed on the object’s icon, signifying that the object has been altered. If you want to save the changes you have made, you need to click the Save icon on the Development Client toolbar.

10.3.1 The Info Panel

The following fields on the Information panel provide facts for the Repository object:

The “Show Inherited Fact Values” Check Box

Select this check box to show facts with overridden values supplied through attached or inherited policies. These fact values are read only (non-editable).

Repository Information Subpanel

The Repository Information panel on the Info/Groups page includes the following fields:

NOTE:Tooltip text is available when you mouse over any of these fields.

Description: The nature or purpose of this repository.

In the Fact Editor, this fact is listed as repository.description:

<fact name="repository.description" value="" type="String" />

Repository Enabled: This check box is selected by default. When it is selected (it has a value of true), VMs can be moved to this repository or they can be provisioned from it.

In the Fact Editor, this fact is listed as repository.enabled:

<fact name="repository.enabled" value="true" type="Boolean" />

Healthy: This check box is selected by default. When it is selected (it has a value of true), the repository is designated as being in good health. You can set the health of the object by selecting or deselecting the health check box. Changing the value in this way has an immediate effect unless the value is overriden by an attached policy. For more information, see Section A.0, Grid Object Health Monitoring

In the Fact Editor, this is fact is listed as repository.health:

<fact name="repository.health" value="true" type="Boolean" />

Type: Select the repository type for this Repository object by selecting an option from the drop-down list.

In the Fact Editor, this fact is listed as repository.type:

<fact name="repository.type" value="local" type="String" />

The following table includes information about the various repository types:

Table 10-1 Repository Types and Descriptions

Repository Type

Description

Development Client Icon

local

The default repository on a host server. Each host server starts with its own local repository, which has the same name as the server’s Resource Grid object.

NAS (Network Attached Storage)

Represents a NAS device connected to host servers (for example, NFS mount). This NAS device must be mounted and available on all host servers associated with this Repository Grid object.

SAN (Storage Area Network)

Represents an iSCSI or Fibre Channel SAN. Currently supported only with the vsphere provisioning adapter.

datagrid

The shared datagrid repository (named zos) is located on the Orchestrate Server and is accessible to all host servers in the datagrid. By default, each host server has access to the zos datagrid repository.

virtual

Represents an externally managed virtual disk (for example, Amazon EC2).

IMPORTANT:If you have a vSphere environment with an iSCSI datastore based on an ESX 3.5 (or previous) host, the Development Client incorrectly displays its type as local rather than SAN. This misrepresentation affects the accuracy of the VM host assignment (how the repositories are scored in the plan), and could possibly affect VM migration validation.

To work around this issue, set the type to SAN. You need to check that this setting is retained when another VM host or Repository discovery is executed.

SAN ID: (SAN repositories only) The SAN ID (the Virtual Fabric ID) for this repository.

In the Fact Editor, this fact is listed as repository.id:

<fact name="repository.id" value="test1" type="String" />

Root Location: The repository’s logical root location. You can also think of this as the base location for all VM files and subdirectories contained within this repository.

In the Fact Editor, this fact is listed as repository.location:

<fact name="repository.location" value="/" type="String" />

The table below provides some examples you can consider as you enter a shared root path in this field. For more information, see Best Practices for Entering Repository File Paths.

Table 10-2 Repository Types and Root Location Examples

Repository Type

Root Location Examples

local

  • / (root)

  • c:/vm

NAS (Network Attached Storage)

This is the mount point that is assumed to be the same on every host server with a connection to this NAS.

  • /u

  • /mnt/myshareddisk

SAN (Storage Area Network)

Not required.

datagrid

grid:///vms

virtual

  • / (root)

  • c:/vm

VM Config Search Path: The relative path (from repository.location) to be used during discover of VM configuration files. This fact also implicitly includes the resource.preferredpath fact. For xen30 repositories, the default path is /etc/xen/vm.

In the Fact Editor, this fact is listed as an array:

<fact name="repository.searchpath">
  <array>
    <string>/etc/xen/vm</string>
  </array>
</fact>

IMPORTANT:If you use this field, do not include a leading forward slash ( / ) in the path. For more information, see Best Practices for Entering Repository File Paths.

The button opens the Attribute element values dialog box, where you can add, remove, or edit the path (element values) in an array of path choices.

The table below provides some examples you can consider as you enter a search path in this field.

Table 10-3 Repository Types and VM Config Search Path Examples

Repository Type

VM Config Search Path Examples

local

/etc/xen/vm

NAS (Network Attached Storage)

Each of these is the relative path from the location to search for VM configuration files. Null specifies to search the whole mount.

  • my_vms

  • saved_vms

  • null (no path entry)

SAN (Storage Area Network)

Not required.

datagrid

grid:///vms

virtual

 

Preferred Storage Path: The relative path (from repository.location) where you want PlateSpin Orchestrate to place the VM files after a move or a clone operation.

In the Fact Editor, this fact is listed as repository.preferredpath:

<fact name="repository.preferredpath" value="" type="String" />

IMPORTANT:If you use this field, do not include a leading forward slash ( / ) in the path. For more information, see Best Practices for Entering Repository File Paths.

Table 10-4 Repository Types and Preferred Storage Path Examples

Repository Type

Preferred Storage Path Examples

local

var/lib/xen/images for Xen VMs

NAS (Network Attached Storage)

my_vms

SAN (Storage Area Network)

Not required.

datagrid

grid:///vms

virtual

Capacity (MB): The maximum amount (in MB) of storage space available to VMs. The default (-1) designates an unlimited amount of space.

In the Fact Editor, this fact is listed as repository.capacity:

<fact name="repository.capacity" value="-1" type="Integer" />

Used Space (MB): The amount (in MB) of storage space used for VMs.

In the Fact Editor, this fact is listed as repository.usedspace:

<fact name="repository.usedspace" value="0" type="Integer" />

Free Space (MB): The amount (in MB) of storage space available to new VMs. The value is always set to -1, which designates an unlimited amount of space.

In the Fact Editor, this fact is listed as repository.freespace:

<fact name="repository.freespace" value="-1" type="Integer" />

Efficiency: Enter an efficiency coefficient that PlateSpin Orchestrate uses to calculate the cost of moving VM disk images to and from the repository. This value is multiplied by the disk image size (in MB) to determine an efficiency score. A score of zero (0) means no cost (very efficient).

In the Fact Editor, this fact is listed as repository.efficiency:

<fact name="repository.efficiency" value="1.0000" type="Real" />

Stored VMs: The VM images stored in this repository. The list is aggregated from individual VM facts.

In the Fact Editor, this fact is listed as an array:

<fact name="repository.vmimages">
  <array type="String">
  </array>
</fact>

You can edit this array by clicking the button to open the Attribute Element Values dialog box, where you can add, remove, or edit the VM host IDs (element values) in an array of VM host ID choices.

Compatible VM Hosts: The VM hosts capable of using this repository. The list is aggregated from individual VM facts.

In the Fact Editor, this fact is listed as an array:

<fact name="repository.vmhosts">
  <array>
    <string>tszen4_xen30</string>
  </array>
</fact>

You can edit this array by clicking the button to open the Attribute element values dialog box, where you can add, remove, or edit the VM host IDs (element values) in an array of VM host ID choices.

Accessed By Provision Adapters: The provisioning adapter jobs that are allowed access to VMs on this repository.

In the Fact Editor, this fact is listed as an array:

<fact name="repository.provisioner.jobs">
  <array>
    <string>xen30</string>
  </array>
</fact>

You can edit this array by clicking the button to open the Choose Grid Objects dialog box, where you can add or remove provisioning adapters for the array of provisioning adapter choices.

NOTE:In the Fact Editor, you edit the provisioning adapter array by using the Attribute Element Values dialog box.

SAN Adapter Configuration

SAN Adapter Vendor: (SAN repositories only) The name of the vendor of the SAN.This should be adapter specific, such as iqn, npiv, emc. An empty field (that is, no value in the string) indicates that bind/unbind is a noop (no operation performed).

In the Fact Editor, this fact is listed as repository.san.vendor:

<fact name="repository.san.vendor" value="" type="String" />

SAN Transport: (SAN repositories only) From the drop-down list, select iSCSI or Fibre Channel to indicate the type of SAN transport this repository uses.

In the Fact Editor, this fact is listed as repository.san.type:

<fact name="repository.san.type" value="" type="String" />

10.3.2 Best Practices for Entering Repository File Paths

Use the following guidelines in scenarios where you need VM repositories.

Creating a Repository to Use with New VMs

If you are creating a repository for new VMs that you will eventually provisions:

  1. In the Root Location field, specify the location for the new repository.

    Example: /vms_new

  2. In the Preferred Storage Path field, specify the path to your image file store (relative to the root location path). This becomes the path for VM configuration files and VM image files when you associate a VM with this repository.

    Example: images (no leading forward slash)

    Because the fields are concatenated, the provisioning adapter searches for the existing VM files in /vms_new/images.

Creating a Repository to Use with Existing VMs

Use this procedure when you already have VMs in your grid and a store for the VM configuration and disk image files already exists.

  1. In the Root Location field, specify the shared location for this repository.

    Example: /vms_new

  2. In the VM Config Search Path field, specify the search path to your existing configuration file store (relative to the Root Location path).

    Example: old_config (no leading forward slash)

    Because the fields are concatenated, the provisioning adapter searches for the existing VM configuration files in /vms_new/old_config.

  3. In the Preferred Storage Path field, specify the path to your existing image file store (relative to the root location path).This also becomes the path for VM configuration files and VM image files when you associate a VM with this repository.

    Example: all_images (no leading forward slash)

    Because the fields are concatenated, the provisioning adapter searches for the existing VM files in /vms_new/all_images.

Creating a Repository for Existing VMs with Shared Root Locations and Separate Configuration Directories

Use this procedure when you want to create a repository for existing VMs that have a shared root path but separate configuration file directories such as /vms_new/old_config1 and /vms_new/old_config2).

  1. In the Root Location field, specify the shared location for this repository.

    Example: /vms_new

  2. In the VM Config Search Path field, specify the search paths to your existing configuration file store (relative to the Root Location path).

    Example: Adjacent to the VM Config Search Path field, click , click Add element, enter old_config1 (no leading forward slash), click OK, click Add element again, specify old_config2 (no leading forward slash), then click OK.

    Because the fields are concatenated, the provisioning adapter searches for the existing VM configuration files in the array consisting of /vms_new/old_config1 and /vms_new/old_config2.

  3. In the Preferred Storage Path field, specify the path to your existing image file store (relative to the Root Location path).This path also becomes the path for VM configuration files and VM image files after a move or clone when a VM has been associated with this repository.

    Example: all_images (no leading forward slash)

    Because the fields are concatenated, the provisioning adapter searches for the existing VM files in /vms_new/all_images.

10.3.3 Groups

This section of the Info/Groups page lists the groups of Repository objects in the grid. Click Choose to open the repository Group selection dialog box. In this dialog box, you can choose which Repository Groups to display in the Explorer Panel by selecting a group, then clicking Add or Remove to move it to or from the Source Repository Groups list.