commvault.com commvault.com
Solved

vCentre authentication failed

  • 23 June 2021
  • 5 replies
  • 2619 views
K
Rank
Userlevel 2
Badge +8

Over the past weekend, we had a VM FULL backup job failed because of failure with vCentre authentication.

 

After changing to a new username and restarting the VMware vSphere Web Client service, the job ran successfully, as well as all the incremental VM backup jobs since.

 

However, what’s annoying me is that, with the same (new) username and password, in the Virtual Server Instance Properties, I still got “Connection refused” message

 

 

So, I don’t quiet understand how come the backup job was fixed whereas the vCentre authentication is still not working ?

 

Thanks,

 

Kelvin

 

 

 

icon

Best answer by Dan White 29 June 2021, 23:48

View original

5 replies

D
Rank
Userlevel 4
Badge +8

Hello @Kelvin 

This is one of two things.

Can you make sure that the VSA proxy has the required port access to vCenter and the ESX hosts? You can identify the VSA proxy by going to the “Proxies tab” shown in your screen shot.

 

We need to ensure that port 443 is opened from the VSA proxy to the vCenter server and port 902 is opened to the ESX hosts in the VMware environment.

 

Once this is verified, we need to ensure that the ccloud\Commvault user account has the required permissions from VMware.

 

If both of these conditions are met, the authorization should be successful.

"If you give a man a fish, you feed him for a day. If you teach a man to fish, they will probably burn your spot"
K
Rank
Userlevel 2
Badge +8

Hi @Dan White ,

Under the Proxy tab, it showed a Client Group called “Infrastructure”

 

And if I click the Proxy ESX Server drop down box, it does allow me to browse the vCentre

So, I assume the username, password and ports must be working then ?

 

OK, that being said, the Client Group “Infrastructure” has 5 Servers

 

Mil-Commvault-2 is the backup Server in question. It also serves a proxy Server to vCentre, and the port 443 is good on it, however, the port 902 is not good but I’m not too sure if this port is relevant... 

Because we have another Commvault Server, on which the port 902 also doesn’t work, only the port 443 works but that Commvault Server doesn’t have any authentication problem to the vCentre...

 

mil-ccloud-ma and mil-ccloud-nas are the other 2 media agents but they are not really in use anymore, but, is it the case that port 443/902 need to be opened on them as well ?

 

Thanks,

 

Kelvin 

Damian Andre
Rank
Userlevel 7
Badge +23

Hey @Kelvin - Port 902 is only used to pull data from ESXi primarily with NBD transport mode, so not required for discovery or initial communication with vCenter - you should be good there with 443 open for the vCenter client.

It does seem like the discovery window is attempting to use a proxy which may not be able to establish a connection, whereas the actual backup job may cycle through all of them until finding one that works. The implemented logic may not be the same when entering credentials on the vCenter client/instance.

Does the proxy ESX server browse work instantly or does it take a few seconds? I wonder if that detail is cached which is why it shows. Rather than leaving the infrastructure group on the proxy list, try set Mil-Commvault-2 manually and see if that works.

Either way, the behavior is strange and should be fixed, but if that works it might give us some more information about what is going on. I believe the EvMgrS.log on the CommServe should also provide detail on where its routing the connection request before displaying the error.

 

K
Rank
Userlevel 2
Badge +8

@Dan White @Damian Andre  “Rather than leaving the infrastructure group on the proxy list, try set Mil-Commvault-2 manually and see if that works.” ----  Yes, it worked !!!

 

Now I’m wondering why ?

D
Rank
Userlevel 4
Badge +8

@Kelvin There is likely a server in that “Infrastructure” group that has the Virtual Server Agent installed on it, that does not have port access to the ESX and vCenter server. You can create a group with only the proper VSA proxies and assign that group on the VMware Proxies or you can leave it the way it is!

"If you give a man a fish, you feed him for a day. If you teach a man to fish, they will probably burn your spot"

Reply


Terms & ConditionsCookie settings