Skip to main content

Method to change vSphere access credentials via command line?

Thread needs solution

We're just starting our Acronis Backup 12.5 on-premise deployment.  Due to government regulations we have tight security requirements.  One of them is to frequently change passwords, even of system and local accounts.    We're not a large shop, but when you start to add up all the segregated environments, it turns out we're looking at deploying a total of 42 vmware virtual appliances spread across 8 Acronis Management Servers.

Is there a way via command line to change the vsphere/ESX access credentials?  If so, then we have some hope of being able to automating the update process.

Thanks,

Cathy

0 Users found this helpful
frestogaslorastaswastavewroviwroclolacorashibushurutraciwrubrishabenichikucrijorejenufrilomuwrigaslowrikejawrachosleratiswurelaseriprouobrunoviswosuthitribrepakotritopislivadrauibretisetewrapenuwrapi
Posts: 22
Comments: 3800

Hi Cathy,

While there is no publicly available command line interface yet for accomplishing this particular task (we're planning to make it available via REST API in future versions), there is an alternative method which should help: you can change the credentials to access the vSphere vCenter/ESXi host for all Agents for VMware at once if you check the "Details" of the ESXi host/vCenter in the web console: Devices -> VMware -> select "Hosts and Clusters" in the tree and select vCenter/ESXi host in the table -> click Details -> change credentials. See example:

What will happen is that all Agents for VMware registered on the management server will be updated with the new credentials for corresponding ESXi host/vCenter. Thus you won't need to change the credentials for each agent individually (as you would do it from Settings -> Agents).

Thank you.

Thank for the update.  As I only have a single Agent for VMware per ESX host, that method doesn't save me anything.  I would still need to manually make 42 updates and logon to 8 different Acronis Management servers to do it.  The command line would have allowed me to automate it and actually have our password manager product perform the task.

 

frestogaslorastaswastavewroviwroclolacorashibushurutraciwrubrishabenichikucrijorejenufrilomuwrigaslowrikejawrachosleratiswurelaseriprouobrunoviswosuthitribrepakotritopislivadrauibretisetewrapenuwrapi
Posts: 22
Comments: 3800

Hi Cathy,

Automation of management of multiple agents can be implemented customly with help from our Support and/or Professional Services teams. I've asked our teams and your account manager to contact you to discuss further steps.

This kind of automation will indeed be required, but only if you have 42 independent (standalone) ESXi hosts which are not managed by a vCenter. If the ESXi hosts are managed by vCenter, then note that connecting Agents for VMware directly to ESXi hosts is not recommended - instead the Agents should communicate with the vCenter in order to properly maintain the vSphere infrastructure. In addition to simplified bulk management (method from my previous comment will apply), this approach would let you reduce the number of required agents - one agent per vSphere cluster is usually sufficient and there is no need to have an agent per each ESXi host. In some cases even a single agent is sufficient as long as it can sustain the required backup load - the size of the backed up VMs data is what matters first of all - not the amount of ESXi hosts.

In other words your requirement to manage such big amount of agents might be caused by misconfiguration of the initial setup of the backup environment, and it should be reviewed separately.

Thank you.

I didn't fully explain our environment but would welcome the opportunity to do so with someone to see if we could scale down some our virtual appliances.   We have the challenge that half of the environment (and half of the Acronis Management servers) are part a contractually delivered system that isn't very flexible in their design and we share the same vcenter.   I look forward to hearing from someone.

Someone from CDW (our reseller) did reach out today to discuss setting up a meeting with someone next week to discus our architecture.  Since this project is under really tight deadlines, perhaps in the meantime you can answer some questions that caused the architecture to be the way it is.

I have a single vcenter that controls two different applications within the same domain.  Each application has it's own ESX servers and physical Acronis Management Server.  VM's for app #1 need to be managed by Acronis #1 and VM's for app #2 need to be managed by Acronis #2.   

If I connected the Acronis VM Appliance to vcenter, I would need to have two of them so that say Acronis VM App #1 connected to Acronis #1 and Acronis VM App #2 connected Acronis #2.   Would that be ok?  I was concerned about having the vsphere connected to multiple Acronis Management servers.

Following up on that, App #1 was delivered as a pre-installed system from a vendor.  It arrived with an Acronis VM on each ESX server (they have 8).  If App #1 can't be changed due to contractual issues, would it be ok to run a mixture?  Leave it as it is, but create Acronis VM App #2 connected to vcenter to handle all the VMs on the App #2 ESX servers? (There are 3.)  Assuming the load was ok, that would at least eliminate 2 Acronis VM's.

How we got to 42 (44 actually, I missed 2), is because what I just described was a single environment.  We actually have 4 of those environments each with their own vcenter, 2 Acronis Management Servers and 11 ESX servers. 

Thanks again.  Any insight you provide is appreciated.

Cathy 

  

frestogaslorastaswastavewroviwroclolacorashibushurutraciwrubrishabenichikucrijorejenufrilomuwrigaslowrikejawrachosleratiswurelaseriprouobrunoviswosuthitribrepakotritopislivadrauibretisetewrapenuwrapi
Posts: 22
Comments: 3800

Hi Cathy,

If you need to have the same vCenter managed from 2 separate Acronis Management Servers (AMS) installations, then it can be done - both AMSes will act independently and Agents for VMware (appliances) can be all connected to this vCenter even if these agents are managed by 2 separate AMSes - it's perfectly normal situation.

If you need to have limited visibility into vCenter infrastructure from 2 AMSes, e.g. where 1 AMS shows VMs from one datacenter (I assume "app #1" and "app #2" are logically isolated on vSphere Datacenter level), while 2nd AMS shows VMs from 2nd datacenter, then it can be implemented by using different vSphere user for agents connected to 1st and 2nd AMSes. Example:

- AMS #1 with Agent #1.1 + Agent #1.2

-- Agents #1.1 + #1.2 are connected to vCenter using "user #1"

- AMS #2 with Agent #2.1 + Agent #2.2

-- Agents #2.1 + #2.2 are connected to vCenter using "user #2"

Example from our lab: there is a vCenter (10.250.194.69) with 2 Datacenters under it: "PMDatacenter" + "ZCloudLegacy". I've created a "TestBackup" user which is granted with "Administrator" privileges on vCenter level without propagation to child objects AND it is granted with "Administrator" privileges on "PMDatacenter" object with enabled propagation (right-click on object -> Edit permissions):

Datacenter level permissions for "TestBackup" user:

vCenter level permissions for "TestBackup" user:

In Acronis Backup interface I've configured the agent to use "TestBackup" user to connect to vSphere (Settings->Agents->select agent->Details):

As the result there is vCenter + only "PMDatacenter" child objects can be managed from the backup console (there is no "ZCloudLegacy" datacenter visible):

In your case similar approach can be used (create 2 separate vSphere users to be used by 2 separate AMSes+agents) if you have x8 ESXi hosts in "app #1" united under vSphere datacenter object. All the agents should be connected to the vCenter, but may use different vSphere user credentials: "User #1" which has permissions to access "app #1" and "User #2" for "app #2".

Also the number of agents may potentially be reduced from 8 down to some lower number - this would depend on the size of the data which needs to be processed (data from "app #1"), the available backup window and the bandwidth between the agents and the backup destination.

Thank you.

Thank you for the information.  That is what I needed.   We are working to get connected via vcenter now.