Export of a VM fails due to timeout.

Hello Marc,

It may be related to the account permissions as you mentioned. You can test with the "administrator@vspere.local" account or check if the RR backup account has the following permissions in VMWare.

Rapid recovery ESXi 6 | 6.5 | 6.7 permissions (4039423)

Please let us know the outcome.

Regards,

Luciano

I'll investigate about the forum not letting you post messages.

Hi Luciano

I verified the permissions and they all match what's required. I also tried putting it into the administrators group and it still fails.

I can see the VM get created in vCenter and vCenter logs show successful actions. It's just when RR is needing to export the data is where it stalls. Nothing in the logs on either side show what's happening.

We are configured to use direct backup from the SAN and I'm wondering if this is causing the issue. Does the export process leverage the same network paths as the backup process does?

Also still having a heck of a time posting to this forum. Replies keep failing with "An error occurred. Please try again or contact your administrator".

The exports to vCenter are performed through the port 443. Here is the list of the ports used by Rapid Recovery: Default ports used by Rapid Recovery (4036155)

It seems there may be something blocking the communication. If not, do you have the ability to perform an export from another Rapid Recovery Core server?

You can also contact support to open a case from here.

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 Luciano,

I did try exporting from another Rapid Recovery server that's in the same site as the vCenter server and the same timeout issue occurred. I'm going to take a further look at ports open and maybe consider a support case.

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. 

You mentioned 443 an 8006 earlier which I did find reference in the manual but not 902 - was that a VMware port for vC-ESXi? 

My bad my friend, as we are talking about Quest, my bad. Port 8006 is the Quest port used for their services, not for exports, that is my fault, good call. For VMware access, you just need the VMware ports, 443 for secure access and port 902 for the VMware api calls. 

Default ports used by Rapid Recovery (4036155) (quest.com)

That's my own brain fart, you don't need 8006 for VMware no.