Migrating back from Vcloud Director

Hello,

I am testing the VRP platform. The scenario is:

- main site: VMware Vcenter

- standby site: Vcloud Director

The migration from Vcenter to VCD works fine. After the migration, the VRP data movers are connected/consistent/active with lag 0. Unfortunately I cannot migrate back because there is an error "Host is not added to the IMS on the recovery data center.". And indeed, the host remains on the source data mover, where it is shown as disconnected (it is not moved by the Migrate action to the standby data mover).

I am completely stuck and out of ideas. Am I doing something wrong?

4 Replies
Highlighted

Re: Migrating back from Vcloud Director

Hi,

is this a Linux VM?

check 

/var/opt/VRTSsfmh/logs/

and there look through 

dr_sites.log

My guess is either the VM can't reacht the IMS in Vcloud. or the IMS in the vCloud can't reach the Vm.

either routing or dns? Did you change the network? Did you update your dns then?

 

 

Re: Migrating back from Vcloud Director

In my test lab networking is very simple. All hosts (Resiliency manager, IMS on main, IMS on standby, Data mover on main, data mover on standby and even the migrated VM (the "host" as it is called in data mover terminology) are in the same LAN.

Yes, it is a Linux VM. The indicated log contains something pretty strange:

2017-10-26 16:41:17 [debug] 3527 local_ims_attach: Executing command [/opt/VRTSsfmh/bin/xprtlc -l https://ims.lab.gts.ro:5634/world/getvitals]
2017-10-26 16:41:17 [debug] 3527 local_ims_attach: Command output [{
"XPRTLD_VERSION" :  "7.0.125.0",
"LOCAL_NAME" : "ims.lab.gts.ro",
"LOCAL_ADDR" : "193.226.171.251",
"PEER_NAME" : "ave-01.lab.gts.ro",
"PEER_ADDR" : "193.226.171.242",
"LOCAL_TIME" : "1509023403",
"LOCALE" : "en_US.UTF-8",
"DOMAIN_MODE" : "TRUE",
"QUIESCE_MODE" : "RUNNING",
"OSNAME" : "Linux",
"OSRELEASE" : "2.6.32-642.15.1.el6.x86_64",
"CPUTYPE" : "x86_64",
"OSUUID" : "{00010050-5601-000b-0000-000000000000}",
"DOMAINS" : {
    "sfm://ims.lab.gts.ro:5634/" : {
        "admin_url" : "vxss://ims.lab.gts.ro:14545/sfm_admin/sfm_domain/vx",
        "primary_broker" : "vxss://ims.lab.gts.ro:14545/sfm_agent/sfm_domain/vx"
        }
    }
}
]
2017-10-26 16:41:17 [debug] 3527 local_ims_attach: IMS [ims.lab.gts.ro] is reachable from host.
2017-10-26 16:41:17 [debug] 3527 local_ims_attach: Network is up
2017-10-26 16:41:17 [debug] 3527 local_ims_attach: Hostname to use in reverse getvitals = ave-01
2017-10-26 16:41:17 [debug] 3527 local_ims_attach: Executing command [/opt/VRTSsfmh/bin/xprtlc -u nobody -l https://ims.lab.gts.ro/https://ave-01:5634/world/getvitals]
2017-10-26 16:41:17 [debug] 3527 local_ims_attach: Command output [HTTP/1.1 500 Error in proxy

500 Error in proxy]
2017-10-26 16:41:17 [debug] 3527 local_ims_attach: not reachable by hostname: ave-01
2017-10-26 16:41:17 [debug] 3527 local_ims_attach: this system's IPs: 193.226.171.242/28
2017-10-26 16:41:17 [debug] 3527 local_ims_attach: Trying reverse getvitals by hostname= ave-01
2017-10-26 16:41:17 [debug] 3527 local_ims_attach: Executing command: /opt/VRTSsfmh/bin/xprtlc -u nobody -l https://ims.lab.gts.ro/https://ave-01.lab.gts.ro:5634/world/getvitals
2017-10-26 16:41:17 [debug] 3527 local_ims_attach: Command output: HTTP/1.1 500 Error in proxy

500 Error in proxy
2017-10-26 16:41:17 [error] 3527 local_ims_attach: Cannot contact host from Central server [ims.lab.gts.ro]
2017-10-26 16:41:17 [debug] 3527 local_ims_attach: Modifying script execution retry time to one min. Exiting.
2017-10-26 16:42:19 [debug] 3516 local_ims_attach: Start local IMS attachment
2017-10-26 16:42:19 [debug] 3516 local_ims_attach: exec_cmd: executing [/usr/sbin/dmidecode -s system-product-name]
2017-10-26 16:42:19 [debug] 3516 local_ims_attach: exec_cmd: exit code [0]
2017-10-26 16:42:19 [debug] 3516 local_ims_attach: exec_cmd: output [VMware Virtual Platform

The hostname should be ave-01.lab.gts.ro and it resolves in all directions.

Re: Migrating back from Vcloud Director

Wow.. i think it's firewall on the VM.

Re: Migrating back from Vcloud Director

I can confirm, the firewall was at fault.

Thanks for the hint.