OpenNebula

Log example:

Fri Aug 17 00:23:28 2012 [TM][I]: Command execution fail: /var/lib/one/remotes/tm/shared/clone ONE341:/var/lib/one/datastores/102/214fe21493566dc5237d799be7e54b3d openvz.sndnb.cipherspace.net:/vmfs/volumes/0/153/disk.0
Fri Aug 17 00:23:28 2012 [TM][I]: clone: Cloning ../../102/214fe21493566dc5237d799be7e54b3d in openvz.sndnb.cipherspace.net:/vmfs/volumes/0/153/disk.0
Fri Aug 17 00:23:28 2012 [TM][E]: clone: Command "cd /vmfs/volumes/0/153; cp -r ../../102/214fe21493566dc5237d799be7e54b3d /vmfs/volumes/0/153/disk.0" failed: cp: cannot stat `../../102/214fe21493566dc5237d799be7e54b3d': No such file or directory
Fri Aug 17 00:23:28 2012 [TM][E]: Error copying ONE341:/var/lib/one/datastores/102/214fe21493566dc5237d799be7e54b3d to openvz.sndnb.cipherspace.net:/vmfs/volumes/0/153/disk.0
Fri Aug 17 00:23:28 2012 [TM][I]: ExitCode: 1
Fri Aug 17 00:23:28 2012 [TM][E]: Error executing image transfer script: Error copying ONE341:/var/lib/one/datastores/102/214fe21493566dc5237d799be7e54b3d to openvz.sndnb.cipherspace.net:/vmfs/volumes/0/153/disk.0

This specific case failed due to the fact that the datastore roots under /vmfs/volumes/ were symlinks to NFS mounts. Unexpected results from walking up a directory tree with '..' across symlinked mount points are to be expected.

The best way to avoid those problems is to not use ".." to get to a directory that you can easily use a name for. Specifically, the /var/lib/one/remotes/tm/{shared,vmware,qcow2}/{ln,clone} scripts all have this line:

SRC_PATH="../../${SRC_PATH##"$DS_DIR/"}"

I think these all should be replaced with a less fragile construction:

SRC_PATH="$RMT_DS_DIR/${SRC_PATH##"$DS_DIR/"}"

This change would match the way DST_PATH is being set in the neighboring 'mvds' scripts.