SSH datastore mvds does not copy back to frontend

Community Support
1

Hi guys,

I have the following issue. I wanted to try ssh datastores (we only used Ceph and NFS until now) and therefor created two Datastores. When the VM is instantiated the image is transferred correctly via ssh to the system datastore on the host. When the machine is shutdown it is not transferred back to the frontend. The tm tries to copy it locally on the kvm host to the corresponding imagedatastore dir (when i create that dir it actually gets copied there)

in the log i see:

Command execution fail: /var/lib/one/remotes/tm/ssh/mvds kvm-host-name:/var/lib/one//datastores/113/2228/disk.0 /var/lib/one//datastores/112/fca4482948f631360567b1cdbc6fb45a 2228 112

and

+ SRC=kvm-host-name:/var/lib/one//datastores/113/2228/disk.0 Tue May 10 10:15:49 2016 [Z0][TM][I]: + DST=/var/lib/one//datastores/112/fca4482948f631360567b1cdbc6fb45a Tue May 10 10:15:49 2016 [Z0][TM][I]: + VMID=2228 Tue May 10 10:15:49 2016 [Z0][TM][I]: + DSID=112 Tue May 10 10:15:49 2016 [Z0][TM][I]: + '[' -z '' ']' Tue May 10 10:15:49 2016 [Z0][TM][I]: + TMCOMMON=/var/lib/one/remotes/tm/tm_common.sh Tue May 10 10:15:49 2016 [Z0][TM][I]: + . /var/lib/one/remotes/tm/tm_common.sh

what did I do wrong here?

we are using Opennebula 4.14.2 on Ubuntu 14.04

that is the configuration of the datastores:

the imagedatastore (accessible on the frontend only) with the following configuration:

<DATASTORE> <ID>112</ID> <UID>0</UID> <GID>0</GID> <UNAME>oneadmin</UNAME> <GNAME>oneadmin</GNAME> <NAME>ssh-test</NAME> <PERMISSIONS> <OWNER_U>1</OWNER_U> <OWNER_M>1</OWNER_M> <OWNER_A>0</OWNER_A> <GROUP_U>1</GROUP_U> <GROUP_M>0</GROUP_M> <GROUP_A>0</GROUP_A> <OTHER_U>0</OTHER_U> <OTHER_M>0</OTHER_M> <OTHER_A>0</OTHER_A> </PERMISSIONS> <DS_MAD><![CDATA[fs]]></DS_MAD> <TM_MAD><![CDATA[ssh]]></TM_MAD> <BASE_PATH><![CDATA[/var/lib/one//datastores/112]]></BASE_PATH> <TYPE>0</TYPE> <DISK_TYPE>0</DISK_TYPE> <STATE>0</STATE> <CLUSTER_ID>100</CLUSTER_ID> <CLUSTER>cluster01</CLUSTER> <TOTAL_MB>100666</TOTAL_MB> <FREE_MB>92803</FREE_MB> <USED_MB>2728</USED_MB> <IMAGES> <ID>841</ID> </IMAGES> <TEMPLATE> <BASE_PATH><![CDATA[/var/lib/one//datastores/]]></BASE_PATH> <CLONE_TARGET><![CDATA[SYSTEM]]></CLONE_TARGET> <DISK_TYPE><![CDATA[FILE]]></DISK_TYPE> <DS_MAD><![CDATA[fs]]></DS_MAD> <LN_TARGET><![CDATA[SYSTEM]]></LN_TARGET> <TM_MAD><![CDATA[ssh]]></TM_MAD> <TYPE><![CDATA[IMAGE_DS]]></TYPE> </TEMPLATE> </DATASTORE>

and the system datastore (accessible on the kvm host only) with the following configuration:
<DATASTORE> <ID>113</ID> <UID>0</UID> <GID>0</GID> <UNAME>oneadmin</UNAME> <GNAME>oneadmin</GNAME> <NAME>system-test</NAME> <PERMISSIONS> <OWNER_U>1</OWNER_U> <OWNER_M>1</OWNER_M> <OWNER_A>0</OWNER_A> <GROUP_U>1</GROUP_U> <GROUP_M>0</GROUP_M> <GROUP_A>0</GROUP_A> <OTHER_U>0</OTHER_U> <OTHER_M>0</OTHER_M> <OTHER_A>0</OTHER_A> </PERMISSIONS> <DS_MAD><![CDATA[-]]></DS_MAD> <TM_MAD><![CDATA[ssh]]></TM_MAD> <BASE_PATH><![CDATA[/var/lib/one//datastores/113]]></BASE_PATH> <TYPE>1</TYPE> <DISK_TYPE>0</DISK_TYPE> <STATE>0</STATE> <CLUSTER_ID>100</CLUSTER_ID> <CLUSTER>cluster01</CLUSTER> <TOTAL_MB>0</TOTAL_MB> <FREE_MB>0</FREE_MB> <USED_MB>0</USED_MB> <IMAGES/> <TEMPLATE> <BASE_PATH><![CDATA[/var/lib/one//datastores/]]></BASE_PATH> <SHARED><![CDATA[NO]]></SHARED> <TM_MAD><![CDATA[ssh]]></TM_MAD> <TYPE><![CDATA[SYSTEM_DS]]></TYPE> </TEMPLATE> </DATASTORE>

2

Seems like your hitting bug http://dev.opennebula.org/issues/4235 (no clue why they didn’t fix this prior to releasing 4.14). You can use the patched script in that bugreport or just replace the content of the mvds script with the script below:

#!/bin/bash -x

# -------------------------------------------------------------------------- #
# Copyright 2002-2015, OpenNebula Project, OpenNebula Systems                #
#                                                                            #
# Licensed under the Apache License, Version 2.0 (the "License"); you may    #
# not use this file except in compliance with the License. You may obtain    #
# a copy of the License at                                                   #
#                                                                            #
# http://www.apache.org/licenses/LICENSE-2.0                                 #
#                                                                            #
# Unless required by applicable law or agreed to in writing, software        #
# distributed under the License is distributed on an "AS IS" BASIS,          #
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.   #
# See the License for the specific language governing permissions and        #
# limitations under the License.                                             #
#--------------------------------------------------------------------------- #

# mvds host:remote_system_ds/disk.i fe:SOURCE vmid dsid
#   - 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
#   - vmid is the id of the VM
#   - dsid is the target datastore (0 is the system datastore)

SRC=$1
DST=$2

VMID=$3
DSID=$4

if [ -z "${ONE_LOCATION}" ]; then
    TMCOMMON=/var/lib/one/remotes/tm/tm_common.sh
else
    TMCOMMON=$ONE_LOCATION/var/remotes/tm/tm_common.sh
fi

. $TMCOMMON

SRC_PATH="$(arg_path $SRC)"
SRC_HOST="$(arg_host $SRC)"
SRC_PATH_SNAP="${SRC_PATH}.snap"

DST_SNAP="${DST}.snap"

#-------------------------------------------------------------------------------
# Move the image back to the datastore
#-------------------------------------------------------------------------------

log "Moving $SRC to datastore as $DST"
exec_and_log "$SCP -r $SRC $DST" "Error copying $SRC to $DST"

if $SSH $SRC_HOST ls ${SRC_PATH_SNAP} >/dev/null 2>&1; then
    exec_and_log "rsync -r --delete ${SRC_HOST}:${SRC_PATH_SNAP}/ ${DST_SNAP}"
fi

exit 0
3

Thx!
I’ll try it and report back if it works, but seems to be the issue …

4

It works! Thx!

5

good to hear that this fixed your issue