Description of problem:
With the latest MTC 1.6.0 build, the migration get stucks at DVM, the reason is "Service [rsync]: Either "CAfile" or "CApath" has to be configured" on the source cluster. 

Version-Release number of selected component (if applicable):
MTC 1.6.0

How reproducible:
Always

Steps to Reproduce:
Execute a direct migration with DVM model, the process get stucks at DVM. I am seeing below logs on the source cluster.
$ oc -n test2 logs rsync-lk746 -c stunnel -f
[ ] Clients allowed=512000
[.] stunnel 5.56 on x86_64-redhat-linux-gnu platform
[.] Compiled/running with OpenSSL 1.1.1g FIPS  21 Apr 2020
[.] Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI
[ ] errno: (*__errno_location ())
[.] Reading configuration from file /etc/stunnel/stunnel.conf
[.] UTF-8 byte order mark not detected
[.] FIPS mode disabled
[ ] Compression disabled
[ ] No PRNG seeding was required
[ ] Initializing service [rsync]
[!] Service [rsync]: Either "CAfile" or "CApath" has to be configured
[ ] Deallocating section defaults


Actual results:
The DVM get stuck for a long time and finally the DMV filed


Expected results:
The DVM should work well


Additional info:
$ oc -n test2 rsh -c stunnel rsync-d7225
sh-4.4# ls -l /etc/stunnel/certs
total 0
lrwxrwxrwx. 1 root root 14 Sep  6 02:49 tls.crt -> ..data/tls.crt
lrwxrwxrwx. 1 root root 14 Sep  6 02:49 tls.key -> ..data/tls.key
$ oc -n test2 get cm crane2-stunnel-client-config -o yaml
apiVersion: v1
data:
  stunnel.conf: |2

     pid =
     sslVersion = TLSv1.2
     client = yes
     syslog = no
     output = /dev/stdout
     [rsync]
     debug = 7
     accept = 6443
     cert = /etc/stunnel/certs/tls.crt
     key = /etc/stunnel/certs/tls.key
     connect = dvm-test2.apps.cam-tgt-24340.qe.devcluster.openshift.com:443
     verify = 2
kind: ConfigMap