However, having said that, if you extensively make use of vi-fastpass fpauth and manage a lot of targets whether they are ESX(i) or vCenter hosts, you need to understand it is not simply just re-deploying another vMA host. When you add a target to vMA's vi-fastpass, two accounts are provisioned on the host "vi-adminXX" and "vi-userXX", these accounts are associated with an encrypted cipher located on vMA which allows for "fastpass" access to the host without having to re-type the password to the host each time. If you were to re-deploy a new vMA host and add the targets again, your host will not only contain the old entries but now a new set of accounts for your new vMA host. This can be an issue as you start to have stale accounts on your ESX(i) or vCenter host.
To prevent this issue, you can actually backup both vMA's configurations which is primarily stored in a sqlite database and the vi-fastpass credential store. In the following example, I have two ESXi hosts being managed by my primary vMA and I also have a standby vMA DR host in which I will backup the files to.
Note: Again this is not really necessary and you can exclude the vmasessioncache directory as part of your backup
You will first need to "dump" the existing vMA database into a file and provide a name of your choice, you will need to run the following command:
sqlite3 /var/opt/vmware/vMA/vMA.db .dump > vMA.db.backupNext, you will need to "scp" the following files to your vMA DR:
- vi-fastpass encrypted credential store file
- vMA's configuration dealing with vi-fastpass targets + vi-logger
- vMA's default logging configs + paths
sudo mv vMA.conf /etc/vmware/vMA/vMA.confNext, you will restore vMA.db and you will need to run the following command:
sudo sqlite3 /var/opt/vmware/vMA/vMA.db < vMA.db.backup
sqlite3 /var/opt/vmware/vMA/vMA.db .dump
You will need to create a file that provides some dynamic shared libraries for the tool we are going to execute. Create a file under /etc/ld.so.conf.d/vmware-vma using "sudo" and paste the following two lines:
sudo ldconfig -f /etc/ld.so.conf.d/vmware-vmaNow you are ready to run the "migratecredstore" utility which is located under /opt/vmware/vma/bin which will perform the "black magic" and make sure you use sudo.
sqlite3 /var/opt/vmware/vMA/vMA.db "select * from management_info;"You will also need to delete the "new" UUID to ensure that only one exists which should be the "original" UUID, you can so by running the following command substituting your UUID:
sudo sqlite3 /var/opt/vmware/vMA/vMA.db "delete from management_info where myUUID='422E4042-63EE-86D1-D22A-79B6ABCA8D68';"At this point, your vMA DR is now your primary and your old vMA is no longer needed.