Export of a VM fails due to timeout.

Rapid Recovery Core 6.7.0.387

vCenter 7

ESXi Hosts are 6.5

I've attempted twice now to export a protected VM to a new vm back to vCenter and it's failing due to timeout. The progress bar never moves and 0 of x bytes are restored. There are no other error messages than the following vague ones:

A background job of type 'Export to virtual machine', summary 'Export of volumes [\\Hard disk 1] to ['newvmname' on vcenter target 'vcenter:443'] for 'originalvmname' (VMware ESXi export)', has failed.

 The export has failed

 Cannot perform an export task :

 * Timeout Exception: Writing to virtual disks operation has been failed.

The export of 'originalvmname' to 'newvmname' on vcenter target 'vcenter:443' has failed.

 The export has failed

 Cannot perform an export task :

 * Timeout Exception: Writing to virtual disks operation has been failed.

I thought it might be account permissions at first as I was using the dedicated RR backup account so for the second job, I used my account which has full access but that didn't work either. Frustated. 

Not to mention this forum said "Your posting frequency has exceeded allowed rates. Please wait 10 minutes to post again." and I haven't even posted a thing yet. Wonderful!

Parents
  • Hello Marc. Typically in my experience those errors refer to connection errors, however they fall under the blanket of 'permissions' or 'timeout' error. For an example, I can recreate that error if the RR core has access to the vCenter, but not the hosts. Or to the hosts, but not the storage. If the vCenter has multiple NICs, or the hosts  have multiple kernel NICs, check and recheck the paths that the RR core would talk to the vCenter and the hosts. Also yes, at a minimum you will need ports 443 and 8006. From the RR core can you log into the vCenter and the hosts and the storage? Good luck. 

  • Hi phuff,

    Thanks for the info. I never thought about access to the hosts - the RR Core backups directly from the SAN so I know there's access there. But I will definitely double check all required ports are open.

    I can attempt the login to those endpoints from the core today.

  • It's a thing for sure, as technically RR (or any other DP solution) does 'hit' the VC to get access and various other api information, however it will have to 'write' to the hosts themselves. We come across this semi-often when say a host had multiple vkernel NICs, however the one that it uses for VC access is NOT the one that the DP solution has access to, then suddenly jobs start to fail left and right. Think about it like in old ESX days, you'd use 443 to get through the VC, but still need to use 22 for the hosts to use the console transport, cause the communication does route to the hosts, no different today, just uses teh 443 and the 902. 

Reply
  • It's a thing for sure, as technically RR (or any other DP solution) does 'hit' the VC to get access and various other api information, however it will have to 'write' to the hosts themselves. We come across this semi-often when say a host had multiple vkernel NICs, however the one that it uses for VC access is NOT the one that the DP solution has access to, then suddenly jobs start to fail left and right. Think about it like in old ESX days, you'd use 443 to get through the VC, but still need to use 22 for the hosts to use the console transport, cause the communication does route to the hosts, no different today, just uses teh 443 and the 902. 

Children