Storage Subsystem Integration 3.4

The Storage subsystem is highly modular. These drivers are separated into two logical sets:

Datastore Drivers Structure

Located under /var/lib/one/remotes/datastore/<ds_mad>

  • cp: copies/dumps the image to the datastore
    • ARGUMENTS: datastore_image_dump image_id
    • RETURNS: image_source size
    • datastore_image_dump is an XML dump of the driver action encoded in Base 64. See a decoded example.
    • image_source is the image source which will be later sent to the transfer manager :!:
  • mkfs: creates a new empty image in the datastore
    • ARGUMENTS: datastore_image_dump image_id
    • RETURNS: image_source size
    • datastore_image_dump is an XML dump of the driver action encoded in Base 64. See a decoded example.
    • image_source is the image source which will be later sent to the transfer manager.
  • rm: removes an image fromthe datastore
    • ARGUMENTS: datastore_image_dump image_id
    • RETURNS: -
    • datastore_image_dump is an XML dump of the driver action encoded in Base 64. See a decoded example.

:!: image_source has to be dynamically generated by the cp and mkfs script. It will be passed later on to the transfer manager, so it should provide all the information the transfer manager needs to locate the image. To illustrate a few examples:

  • FS driver: DATASTORE_BASE_PATH + md5sum(date + id)
  • iSCSI driver: <base_iqn>:<host>.<vg-name>.<lv-name>

TM Drivers Structure

This is a list of the TM drivers and their action. Note that they don't return anything. If the exit code is not 0, the driver will have failed.

Located under /var/lib/one/remotes/tm/<tm_mad>. There are two types of action scripts: the first group applies to general image datastores and includes (clone, ln, mv and mvds); the second one is only used in conjunction with the system datastore.

Action scripts for generic image datastores:

  • clone: clones the image from the datastore (non-persistent images)
    • ARGUMENTS: clone fe:SOURCE host:remote_system_ds/disk.i size
    • fe is the front-end hostname
    • SOURCE is the path of the disk image in the form DS_BASE_PATH/disk
    • host is the target host to deploy the VM
    • remote_system_ds is the path for the system datastore in the host
  • ln: Links the image from the datastore (persistent images)
    • ARGUMENTS: clone fe:SOURCE host:remote_system_ds/disk.i size
    • fe is the front-end hostname
    • SOURCE is the path of the disk image in the form DS_BASE_PATH/disk
    • host is the target host to deploy the VM
    • remote_system_ds is the path for the system datastore in the host
  • mvds: moves an image back to its datastore (persitent images or save_as)
    • ARGUMENTS: host:remote_system_ds/disk.i fe:SOURCE
    • fe is the front-end hostname
    • SOURCE is the path of the disk image in the form DS_BASE_PATH/disk
    • host is the target host to deploy the VM
    • remote_system_ds is the path for the system datastore in the host
  • mv: moves images/directories across system_ds in different hosts. When used for an image datastore, only the image argument format is used.
    • ARGUMENTS: hostA:system_ds/disk.i|hostB:system_ds/disk.i <OR> hostA:system_ds/|hostB:system_ds/
    • hostA is the host the VM is in.
    • hostB is the target host to deploy the VM
    • system_ds is the path for the system datastore in the host

Action scripts needed when the TM is used for the system datastore:

  • context: creates an ISO that contains all the files passed as an argument.
    • ARGUMENTS: file1 file2 … fileN host:remote_system_ds/disk.i
    • host is the target host to deploy the VM
    • remote_system_ds is the path for the system datastore in the host
  • delete: removes the eithr system datastore's directory of the VM or a disk itself.
    • ARGUMENTS: host:remote_system_ds/disk.i|host:remote_system_ds/
    • host is the target host to deploy the VM
    • remote_system_ds is the path for the system datastore in the host
  • mkimage: creates an image on-the-fly bypassing the datastore/image workflow
    • ARGUMENTS: size format host:remote_system_ds/disk.i size
    • size size in MB of the image
    • format format for the image
    • host is the target host to deploy the VM
    • remote_system_ds is the path for the system datastore in the host
  • mkswap: creates a swap image
    • ARGUMENTS: size host:remote_system_ds/disk.i size
    • size size in MB of the image
    • host is the target host to deploy the VM
    • remote_system_ds is the path for the system datastore in the host
  • mv: moves images/directories across system_ds in different hosts. When used for the system datastore the script will received the directory ARGUMENT
    • ARGUMENTS: hostA:system_ds/disk.i|hostB:system_ds/disk.i <OR> hostA:system_ds/|hostB:system_ds/
    • hostA is the host the VM is in.
    • hostB is the target host to deploy the VM
    • system_ds is the path for the system datastore in the host

:!: You only need to implement one mv script, but consider the arguments received when the TM is used for the system datastore, a regular image datastore or both.

:!: If the TM is only for regular images you only need to implement the first group.

An example VM

Consider a VM with two disks:

NAME   = vm01
CPU    = 0.1
MEMORY = 64
 
DISK   = [ IMAGE_ID = 0 ] # persistent disk
DISK   = [ IMAGE_ID = 1 ] # non-persistent disk

This a list of TM actions that will be called upon the events listed:

CREATE

<tm_mad>/clone <frontend>:<non_pers_image_source> <host01>:<ds_path>/<vm_id>/disk.0
<tm_mad>/ln <frontend>:<pers_image_source> <host01>:<ds_path>/<vm_id>/disk.1

STOP

<tm_mad>/mv <host01>:<ds_path>/<vm_id>/disk.0 <frontend>:<ds_path>/<vm_id>/disk.0
<tm_mad>/mv <host01>:<ds_path>/<vm_id>/disk.1 <frontend>:<ds_path>/<vm_id>/disk.1
<tm_mad_sysds>/mv <host01>:<ds_path>/<vm_id> <frontend>:<ds_path>/<vm_id>

RESUME

<tm_mad>/mv <frontend>:<ds_path>/<vm_id>/disk.0 <host01>:<ds_path>/<vm_id>/disk.0
<tm_mad>/mv <frontend>:<ds_path>/<vm_id>/disk.1 <host01>:<ds_path>/<vm_id>/disk.1
<tm_mad_sysds>/mv <frontend>:<ds_path>/<vm_id> <host01>:<ds_path>/<vm_id>

MIGRATE host01 → host02

<tm_mad>/mv <host01>:<ds_path>/<vm_id>/disk.0 <host02>:<ds_path>/<vm_id>/disk.0
<tm_mad>/mv <host01>:<ds_path>/<vm_id>/disk.1 <host02>:<ds_path>/<vm_id>/disk.1
<tm_mad_sysds>/mv <host01>:<ds_path>/<vm_id> <host02>:<ds_path>/<vm_id>

SHUTDOWN

<tm_mad>/delete <host02>:<ds_path>/<vm_id>/disk.0
<tm_mad>/mvds <host02>:<ds_path>/<vm_id>/disk.1 <pers_image_source>
<tm_mad_sysds>/delete <host02>:<ds_path>/<vm_id>
  • non_pers_image_source: Source of the non persistent image.
  • pers_image_source : Source of the persistent image.
  • frontend: hostname of the frontend
  • host01: hostname of host01
  • host02: hostname of host02
  • tm_mad: TM driver of the datastore where the image is registered
  • tm_mad_sysds: TM driver of the system datastore

Helper Scripts

There is a helper shell script with some functions defined to do some common tasks. It is located in /var/lib/one/remotes/scripts_common.sh

Here are the description of those functions.

  • log: Takes one parameter that is a message that will be logged into the VM log file.
log "Creating directory $DST_DIR"
  • error_message: sends an exit message to oned surrounding it by separators, use to send the error message when a command fails.
error_message "File '$FILE' not found"
  • arg_host: gets the hostname part from a parameter
SRC_HOST=`arg_host $SRC`
  • arg_path: gets the path part from a parameter
SRC_PATH=`arg_path $SRC`
  • exec_and_log: executes a command and logs its execution. If the command fails the error message is sent to oned and the script ends
exec_and_log "chmod g+w $DST_PATH"
  • ssh_exec_and_log: This function executes $2 at $1 host and report error $3
ssh_exec_and_log "$HOST" "chmod g+w $DST_PATH" "Error message"
  • timeout_exec_and_log: like exec_and_log but takes as first parameter the max number of seconds the command can run
timeout_exec_and_log 15 "cp $SRC_PATH $DST_PATH"