5.6 The Repository Object

Repositories are storage areas for VMimage files and VM template files.

If a VM’s files are stored on a particular host server, that VM must be run from that host server. If a VM’s files are stored on a shared repository, that VM can be run on any host server that has access to the shared repository.

Host servers can have multiple repositories associated with them, and some repository types can be associated with multiple host servers as shared repositories. A host server can be associated with repositories stored locally on its server and with shared repositories stored on other machines.

The default size for all repositories is unlimited. To control disk space usage, you can change this default. For more information, see Capacity (Mb): in Repository Information.

The repository groups and their constituent repository objects are displayed in the Explorer panel and the accompanying Repository Admin View of the Development Client.

5.6.1 Repository Groups

Any group object displayed in the Explorer panel represents a collection of similar object types. Groups can also be created automatically, as in the case when a provisioning adapter (PA) discovers a local repository on a VM host. For example, the Xen30 PA, upon discovery of a VM host, automatically creates a local repository for that VM host and places the created repository in a xen30 repository group. You can also create groups manually in the Development Client, either by clicking the Actions menu and choosing Create Repository Group or by right clicking the Repository object (anywhere in the Repository hierarchy) and selecting New Repository Group.

5.6.2 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, that object’s icon is overlaid with the write 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.

Info

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

Show Inherited Fact Values Check Box

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

Repository Information

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

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

Description: Enter information in this box that describes 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 (that is, its value is “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 (that is, its value is “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 (this follows the normal rules of policy inheritance). 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 5-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)

A remote storage location that can be configured as a shared store for VM images (which can be moved) or a block-based disk used by a single VM. This repository can be configured as either iSCSI or Fibre Channel. using iSCSI Qualified Name, NPIV, or EMC.

The modeling of SAN storage requires special setup, particularly when configured as shared storage where LUN masks are created for each of the hosts with visibility to the SAN.

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, VMware Virtual Center).

SAN ID: (SAN repositories only) This field displays 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: Enter the repository’s logical root location in this field. 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 5-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: Enter 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 5-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: Enter 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 5-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): Enter the maximum amount (in megabytes) 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): This is a non-editable field that displays the amount (in megabytes) 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): This is a non-editable field that displays the amount (in megabytes) 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 megabytes) 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: This field displays a list of 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. In this dialog box you can add, remove, or edit the VM host IDs (element values) in an array of VM host ID choices.

Compatible VM Hosts: This field displays a list of 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. In this dialog box you can add, remove, or edit the VM host IDs (element values) in an array of VM host ID choices.

Accessed By Provision Adapters: This field displays a list of 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. In this dialog box you can add or remove provisioning adapters to 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) Enter the name of the vendor of the SAN. This should be adapter specific, for example: iqn, npiv, emc. An empty field (that is, no value in the string) indicates 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" />

Best Practices for Entering Repository File Paths

Because of some limitations in the current (2.0.2) release of PlateSpin Orchestrate, we suggest that you 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 provision, use the following steps:

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

    Example: /vms_new

  2. In the Preferred Storage Path field, enter 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

When you already have VMs in your grid, so a store for the VM configuration and disk image files already exists,

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

    Example: /vms_new

  2. In the VM Config Search Path field, enter 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, enter 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

When you want to create a repository for existing VMs that have a shared root path but separate configuration file directories, (for example, /vms_new/old_config1 and /vms_new/old_config2)

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

    Example: /vms_new

  2. In the VM Config Search Path field, enter 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, enter 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, enter the path to your existing image file store (relative to the Root Location path). This path will also become 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.

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 and then clicking Add or Remove to move it to or from the Source Repository Groups list.

5.6.3 The Repository Policies Tab

The Polices tab opens a page that contains a policy viewer for each of the policies associated with a Grid object.

NOTE:You can edit a policy by right-clicking a policy icon, selecting Edit Policy and clicking the Save icon.

5.6.4 The Repository Health Debugger Tab

The Health Debugger is a common Admin view in the Development Client for most Grid objects. For information about this tool, see Section 6.0, The Health Debugger.

5.6.5 The Repository Constraints/Facts Tab

The Constraints/Facts tab opens a page that shows all of the effective constraints and facts for a Grid object. Each Grid object has an associated set of facts and constraints that define its properties. In essence, by building, deploying, and running jobs on the PlateSpin Orchestrate Server, you can individually change the functionality of any and all system resources by managing an object’s facts and constraints. The Orchestrate Server assigns default values to each of the component facts, although they can be changed at any time by the administrator, unless they are read-only. Facts with mode r/o have read-only values, which can be viewed (that is, using the edit “pencil” icon) but changes cannot be made.

5.6.6 The Repository Action History Tab

The Action History tab is displayed in the administrative view of the Repository object. When you select the Action History tab, a table displays a list of the history for all actions performed on this Grid object.

The Orchestrate Server must be connected to an audit database for the Include Audit Database check box to be available. If the Include Audit Database check box is selected in this view, the action status is not polled. Click the refresh icon in the toolbar to fetch and display fresh data.

For more details about the information listed on the Action History page, see Section D.2.2, Action History in Admin Views of the Development Client.