Skip to main content
commvault.com commvault.com
Solved

NON Domain connected vSphere - failed to get server list

  • September 8, 2022
  • 7 replies
  • 335 views
B
Bit
Forum|alt.badge.img+1

Hey all,

I’m adding a non-domain connected vSphere to my existing Commcell (via the Commserve) and when I connect from the CS box to add the client, the connection failed immediately with:

“failed to get member servers as proc APPGetVSMemberservers returned empty result”

That error occurs after I hit browse on the subclient to view the VMs.

I’m using a full admin vSphere account XXXX@vsphere.local - and I’m thinking this is not a Commvault problem but a domain/vSphere prob. So I’m kinda asking for some insight for those who have added non-domain connected boxes before. 

I have no issues logging into vSphere from a browser on the CS box (full admin, create VMs, delete VMS, etc) - but from CS console on the same box - I get the above error. 

 

Best answer by Brian Spencer

FIXED!!! - I ended up adding the 4 clustered ESXi boxes to the domain along with vCenter and was finally able to list all of the VMs and the start backups. I was never able to get @vsphere. local accounts to work. :/ - but I’m up and running - thanks again to those who chimed in! 

 

 

View original
Did this answer your question?

7 replies

Aplynx
Vaulter
Forum|alt.badge.img+13
  • AplynxVaulter
  • Vaulter
  • 291 replies
  • September 8, 2022

sounds more like you don’t have access nodes \ proxies configured for the VSA

Liam
Mike Struening
B
2 people like this
  • Mike Struening
    Mike Struening
  • B
    Brian Spencer
B
Bit
Forum|alt.badge.img+1
Aplynx wrote:

sounds more like you don’t have access nodes \ proxies configured for the VSA

Thanks! Lemme look into that. 

Mike Struening
1 person likes this
  • Mike Struening
    Mike Struening
B
Bit
Forum|alt.badge.img+1

Looks like this may be my problem:

https://documentation.commvault.com/v11/expert/32132_configuration_of_vsphere_user_accounts.html


“The vCenter user account must have permissions on the vCenter, datacenter, ESX server, and virtual machine levels for any virtual machines to be backed up and restored. The backup for a virtual machine fails if the user does not have permission on the vCenter, datacenter, and ESX server where the virtual machine resides.”

Of course we are running 4 clustered ESXi boxes (also not domain joined) along with vSphere. None have the same account. I’m guess my fix is to join the the VSA along with all the ESXi boxes to the domain. 

Jos Meijer
Commvault Certified Expert
Forum|alt.badge.img+17
  • Jos MeijerCommvault Certified Expert
  • Commvault Certified Expert
  • 638 replies
  • September 9, 2022

A domain relationship is not needed for vCenter backups.

You clearly were able to add the vCenter, thus you configured the pseudoclient with a local vsphere account which succesfully authenticated.
Assuming this account is an admin account on vSphere global level?

If this user is a global admin within vSphere then you have rights on all the objects within vCenter unless you have manually altered the ACL for hosts, vm's and datastores.

If the user is a global admin and there is no ACL customization then there is only one remaining object causing the issue, the VSA.

Either you do not have an active VSA configured in the vCenter pseudoclient as an access node or the configured VSA is unable to communicate with the vCenter on 443 (or another port if you customized this in the vCenter config).

Default port requirements for the VSA:

vCenter TCP 443

ESXi TCP 443 and TCP 902

Hope this helps.

B
1 person likes this
  • B
    Brian Spencer
B
Bit
Forum|alt.badge.img+1
Jos Meijer wrote:

A domain relationship is not needed for vCenter backups.

You clearly were able to add the vCenter, thus you configured the pseudoclient with a local vsphere account which succesfully authenticated.
Assuming this account is an admin account on vSphere global level?

If this user is a global admin within vSphere then you have rights on all the objects within vCenter unless you have manually altered the ACL for hosts, vm's and datastores.

If the user is a global admin and there is no ACL customization then there is only one remaining object causing the issue, the VSA.

Either you do not have an active VSA configured in the vCenter pseudoclient as an access node or the configured VSA is unable to communicate with the vCenter on 443 (or another port if you customized this in the vCenter config).

Default port requirements for the VSA:

vCenter TCP 443

ESXi TCP 443 and TCP 902

Hope this helps.

Thanks, Jos - Yes, it was an admin account but not global - I dont think - just the admin group in vsphere.local. I tried a million different account setups on the CS box including user @ vsphere.local, just user and vsphere.local/user - nothing worked. AND I duped the accounts names across the ESXi cluster and the VSA - still nothing So I’ve decided to add it to the domain (and it should be anyway - I didnt because I was in a hurry to test restores from one VSA to this new VSA) - Anyway I’ll update with my findings on Monday. Thanks to all who chimed in. 

Mike Struening
1 person likes this
  • Mike Struening
    Mike Struening
B
Bit
Forum|alt.badge.img+1
  • Brian Spencer
  • Author
  • Bit
  • 4 replies
  • Answer
  • September 13, 2022

FIXED!!! - I ended up adding the 4 clustered ESXi boxes to the domain along with vCenter and was finally able to list all of the VMs and the start backups. I was never able to get @vsphere. local accounts to work. :/ - but I’m up and running - thanks again to those who chimed in! 

 

 

Mike Struening
Jos Meijer
2 people like this
  • Mike Struening
    Mike Struening
  • Jos Meijer
    Jos Meijer
Jos Meijer
Commvault Certified Expert
Forum|alt.badge.img+17
  • Jos MeijerCommvault Certified Expert
  • Commvault Certified Expert
  • 638 replies
  • September 13, 2022

Good to hear it's working @Brian Spencer 🙂

Mike Struening
B
2 people like this
  • Mike Struening
    Mike Struening
  • B
    Brian Spencer

Reply


Most helpful members this week

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings