Skip to main content
Answer

Disaster Recovery Orchestrator (v6) Error, Failed to Login to vCenter

  • May 17, 2023
  • 5 comments
  • 493 views

Forum|alt.badge.img+1

We’ve been testing our Orchestration Plan and after failover to our DR site, the certs on our vCenters were replaced and broke the connections between our DRO and vCenters. Had to refresh the connection so the DRO can take in the new certs. However, when we tried to failback to our primary site, we had the login error to vCenter. 

The issue was fix when we had to go into the built-in VBR and refresh the connection in VBR itself. 

 

I would tend to think that DRO itself would be able to restore the connections within its built-in VBR and VeeamOne.

 

Let me know what you think or if I’m missing something here.

 

Best answer by MicoolPaul

I agree with your thinking that really this sort of error should be passed back to VRO for you to remediate within the web GUI.

 

Speaking potentially a bit harshly of the product, a lot of what VRO does, feels like it’s running PoSH & API calls against VBR & VONE, instead of native functionality. That’s fine if it wants to use those as its backend, but errors should certainly still be presented back to the front-end for resolution.

 

I’d suggest raising this in the R&D forums (forums.veeam.com) to get product management aware of this in case it’s a bug, and as a feature improvement if it’s not.

5 comments

Chris.Childerhose
Forum|alt.badge.img+21

According to here - Architecture Overview - Veeam Disaster Recovery Orchestrator User Guide there is an agent that gets deployed to your VBR servers to orchestrate recovery so that would mean that the vCenter connection and certs should be confirmed there like you did.  I know it uses the built-in VBR/VONE but still connects to VBR.


Forum|alt.badge.img+1
  • Author
  • Influencer
  • May 17, 2023

Thanks Chris for your reply. 

 

I agree with you that the connections to the vCenters from the built-in VBR should be confirmed after the cert change on the vCenters but I think that DRO should have made that confirmations once the connections have been refreshed from the DRO side instead of doing another manual step of bringing up the built-in VBR console and doing the refresh.

 


MicoolPaul
Forum|alt.badge.img+23
  • Answer
  • May 18, 2023

I agree with your thinking that really this sort of error should be passed back to VRO for you to remediate within the web GUI.

 

Speaking potentially a bit harshly of the product, a lot of what VRO does, feels like it’s running PoSH & API calls against VBR & VONE, instead of native functionality. That’s fine if it wants to use those as its backend, but errors should certainly still be presented back to the front-end for resolution.

 

I’d suggest raising this in the R&D forums (forums.veeam.com) to get product management aware of this in case it’s a bug, and as a feature improvement if it’s not.


Forum|alt.badge.img+1
  • Author
  • Influencer
  • May 26, 2023

Thanks for the suggestion of bringing this to forums.veeam.com.  I will update if I get anything significant from them.

 


Forum|alt.badge.img+1
  • Author
  • Influencer
  • May 29, 2023

Per forums.veeam.com, they will take this up with development and see if implementation without going to the built-in VBR and VONE would be possible. Thanks!