Transfer Manager Driver 3.0

Transfer Manager (TM) architecture is highly modular. There are high level actions that OpenNebula asks the TM to perform, which in turn the TM translates into different tasks depending on the storage model specific configuration. Current release of OpenNebula comes with two different set of action scripts that conforms two different TMs for different storage models (see Configuration Interface). There is information available on how to build custom sets of action scripts to tackle custom configuration of the storage model.

 TM Structure

Structure: The Action Scripts

TM is all about moving images around and performing file system operations on (possibly) remote hosts, so all the actions receive as arguments at least one ORIGIN or one DESTINATION, or both. These have the form:

  <host>:<path>

The different available actions that the TM understands are:

  • CLONE: This action will basically make a copy of the image from ORIGIN to DESTINATION. This can mean different things depending on the storage model configuration (see Sample Configurations)
  • LN: Creates a symbolic link in DESTINATION that points to ORIGIN
  • MKSWAP: Generates a swap image in DESTINATION. The size is given in ORIGIN in MB.
  • MKIMAGE: Creates a disk image in DESTINATION and populates it with the files inside ORIGIN directory.
  • DELETE: Deletes ORIGIN file or directory.
  • MV: Moves ORIGIN to DESTINATION.

Action scripts must conform to some rules to work. These are the general rules:

  • The script should exit with code 0 on success or any other value to indicate failure.
  • Everything written to STDOUT is logged to the corresponding VM log file.
  • In case of failure the error message is written to STDERR surrounding the message with these separators:
ERROR MESSAGE --8<------
error message here
ERROR MESSAGE ------>8--

There is a helper shell script with some functions defined to do some common tasks. It is located in /usr/lib/one/mads/tm_common.sh and can be loaded adding this line at the start of your script:

. /usr/lib/one/mads/tm_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"
  • 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"

Note: This script is placed in /usr/lib/one/mads if you installed OpenNebula in root.

Sample: A Shared Image Repository

As an example here is described how to modify NFS scripts for a different configuration. In this configuration we will have images directory shared but not <VM_DIR>.

tm_ln.sh

This script is responsible of creating a link in <VM_DIR> that points to the original image when it has clone set to โ€œoffโ€. As we are dealing with non shared <VM_DIR> it has to be modified so it creates the remote directory and also makes the link in the destination host.

#!/bin/bash
 
SRC=$1
DST=$2
 
. /usr/lib/one/mads/tm_common.sh
 
SRC_PATH=`arg_path $SRC`
DST_PATH=`arg_path $DST`
DST_HOST=`arg_host $DST`
 
DST_DIR=`dirname $DST_PATH`
 
log "Creating directory $DST_DIR"
exec_and_log "ssh $DST_HOST mkdir -p $DST_DIR"
 
log "Link $SRC_PATH"
exec_and_log "ssh $DST_HOST ln -s $SRC_PATH $DST_PATH"

We added the mkdir command and changed link creation to be executed in the remote machine.

tm_clone.sh

Here the modifications are similar to LN, changed the commands so they are executed in the destination host.

#!/bin/bash
 
SRC=$1
DST=$2
 
. /usr/lib/one/mads/tm_common.sh
 
SRC_PATH=`arg_path $SRC`
DST_PATH=`arg_path $DST`
DST_HOST=`arg_host $DST`
 
log "$1 $2"
log "DST: $DST_PATH"
 
DST_DIR=`dirname $DST_PATH`
 
log "Creating directory $DST_DIR"
exec_and_log "ssh $DST_HOST mkdir -p $DST_DIR"
exec_and_log "ssh $DST_HOST chmod a+w $DST_DIR"
 
case $SRC in
http://*)
    log "Downloading $SRC"
    exec_and_log "ssh $DST_HOST wget -O $DST_PATH $SRC"
    ;;
 
*)
    log "Cloning $SRC_PATH"
    exec_and_log "ssh $DST_HOST cp $SRC_PATH $DST_PATH"
    ;;
esac
 
exec_and_log "ssh $DST_HOST chmod a+w $DST_PATH"

Note the ssh command appended to each of commands.

The rest of the the commands follow similar modifications, executing the commands using ssh on the remote machine.

Adding Custom Remote URLs

When you specify a disk that has โ€œ:โ€ in its path is not treated in any way and it is passed to TM action script directly. This lets us pass things like <hostname>:<path> so you can specify an image that is located in a remote machine that is accessible using ssh or customize clone scripts so it accepts different kinds of URLS. This modification should be done in tm_clone.sh script adding a new option in the case statement. For example, if we want to add ftp support using wget we can add this code:

case $SRC in
ftp://*)
    log "Downloading $SRC"
    exec_and_log "wget -O $DST_PATH $SRC"
    ;;

Note that we are using -O option of wget, that tells where to download the file. This is needed as the file should be in an specific directory and also needs to be correctly named.