WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

How to backup/restore vMA's config + vi-fastpass DB

02.04.2011 by William Lam // 1 Comment

I recently wrote an article on the process of cloning vMA which provides a way of backing up vMA. Due to the ease of deploying vMA as a virtual appliance (using OVF), there aren't too many reasons you would need to backup this virtual machine. If you lost the system for whatever reason, you can easily re-deploy with just a few clicks.

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.

First, you want to make sure you do not have any active vifptarget sessions, this is not a requirement but it can ensure you do not copy over any vMA "session cache" files to your DR site. You can check by doing a long listing in /home/vi-admin/.vmware and looking for the directory vmasessioncache which will contain any active cached sessions if you recently initialized a fastpass target.

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.backup

Next, you will need to "scp" the following files to your vMA DR:

  •  vi-fastpass encrypted credential store file
    • /home/vi-admin/.vmware
  •  vMA's configuration dealing with vi-fastpass targets + vi-logger
    • /home/vi-admin/vMA.db.backup
  •  vMA's default logging configs + paths
    • /etc/vmware/vMA/vMA.conf 

You now should login to your vMA DR host and you should see only two files in the home directory of the vi-admin user: vMA.conf and vMA.db.backup (.vmware directory is a hidden directory in /home/vi-admin)

From here, you will restore vMA.conf and you will need to run the following command:

sudo mv vMA.conf /etc/vmware/vMA/vMA.conf

Next, 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

At this point, we can verify the database contents by just running the ".dump" command:

sqlite3 /var/opt/vmware/vMA/vMA.db .dump

Now, we're not done yet, we need to run one additional tool that will perform some VMware "black magic" which will allow this new vMA to access all your ESX(i) and/or vCenter targets just as you had it before on your primary vMA.

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:

  • /opt/vmware/vma/lib
  • /opt/vmware/vma/lib64

Now you will need to run the following to read in the configuration:

sudo ldconfig -f /etc/ld.so.conf.d/vmware-vma

Now 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.

Once you see the successful message on completing the migration of your credential store, you have now fully restored your original vMA configuration. Here we perform a list of the active servers that was once accessible on primary vMA and initializing a target and verifying that it does in fact work.

One thing to note, if you still have access to your primary vMA, both your vMA's are now in an active/active state, with caveat that your primary vMA is the only one allowed to make any changes. What I mean by this, is when you initially add a host to vMA's fastpass, it not only creates two accounts, but it also associates it's system's UUID as part of the unique identifier which is stored on the host with the key VMAID

This means that if you deleted the target off your vMA DR host, it does not actually remove this entry on your ESX(i) and/or vCenter host. Only the primary vMA which has the matching UUID is able to remove the entry all together when you perform a "vifp removeserver" operation.You can see the system UUID by using the dmidecode utility.

We can also see this within the vMA database, when viewing this on the vMA DR host, you will actually see both entries of the primary and the DR vMA UUIDs because we restored the database with the original vMA's config.

If you need your vMA DR host to be able to modify entries or rotate passwords, you will need to shutdown vMA and update it's bios.uuid within the .vmx entry. You must use the "original" vMA's UUID which you should see from the database by running the following command:

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.

Categories // Uncategorized Tags // credentialstore, vi-fastpass, vma, vMA.db

How to increase capacity of /var/log on vMA 4.1

01.28.2011 by William Lam // 4 Comments

This question pops up from time to time on the VMTN community forums on how to increase the size of /var/log on vMA. By default, the /var/log partition is configured to ~500MB, which is a decent size for system logs, but one of the features of vMA is vilogger which adds a syslog capability for your ESX and ESXi hosts. This allows you to ship all your host logs over to vMA, the problem is the logs are also stored in /var/log along with vMA's system logs. If you are managing several dozen hosts, you can easily fill up this partition using the default configured size.

With vMA 4.0, it was pretty trivial to increase/resize partitions within vMA using LVM and I had written a quick guide on how to do this - How to increase/resize vMA Disks. With the release of vMA 4.1, VMware kind of went backwards and decided not to leverage LVM and lost the benefits with using a volume manager. Resizing the partitions can still be accomplished but it requires a few additional steps and tools. I will show you two methods in which you can increase your /var/log partition, primarily to accommodate larger number of hosts to utilize the vilogger functionality.

Option1: Resize /var/log using gparted 

Here is what a default vMA disk layout looks like and note the size of /var/log

First, you will want to shutdown your vMA host, you may also want to backup any scripts/configs you may have on your vMA host in case you make a mistake and can not recover. Next, you will need to increase the existing virtual disk, by default it is configured for 5GB. In this example, I will increase the disk capacity to 10GB bringing the total to 15GB. You will also need to download a gparted live CD ISO, in this example I am using gparted 0.3.4-11, it is what I have available on my datastore.

Next, you will want to attach the gparted ISO to vMA, you probably will need to add a CD-ROM drive since vMA does not come with one by default. Once you power vMA on, you will need to hit ESC to and select boot from CD-ROM. You should be able to just accept all the defaults and once gparted is loaded, you should see the following screen or something similar depending on the version of gparted you are using.

As you can see, it is the partition layout of your vMA host including the unallocated space, which in this case is 10GB. At a high level, we need to resize the partitions inside the extended partition first before we can resize /var/log partition. First you will select/highlight the "extended (/dev/sd4)" partition which is colored in baby blue color and you will move the right arrow and extend it all the way to the right and then click "Resize/Move" button.

Next, you will select/highlight "/ (dev/sd5)" partition which is colored in blue. Here we want to keep / (root) the same default size of 3.39GB, so we are just going to shift the entire box from the left to far right. You just need to bring the cursor on top of the dark blue section and drag it to the right. Make sure you do not move the left or right arrows, else you will be changing the size of root which is not what we want. Once you have it like the picture below, click on the "Resize/Move" button.

Now you will select/highlight "extended (/dev/sd4)" partition again and you will move the left arrow and drag it towards the right like the picture below and again click on the "Resize/Move" button once you are done.

At this point, your screen should look like the following, if it does not for what ever reason you can "undo" all the changes, since none of these changes take affect until you apply them. 

Now, we will finally increase the size of "/var/log (/dev/sd3)" and consume the full amount of space that we have allocated.

Once you are done, we are now ready to apply these changes, the "apply" button is at the top.

After this, it can take up to several minutes depending on your allocation but if everything went well, you should see this success screen at the end and you just need to reboot the system to see the new changes.

One your vMA host is up, you now should be able to run "df -h" again and you should see that /var/log has now increased with the additional space we assigned it.

Option2: Add a new virtual disk and reconfigure vilogger syslog location

If you did not want to go through the process in option 1 and just want to add another virtual disk and dedicate that for vilogger syslog, you can actually change the path of the logs in /etc/vmware/vMA/vMA.conf. You can control not only the vilogger syslog but also vi-fastpass logs and vilogger daemon logs, but we will only change the "vMALogCollector" which is basically the vilogger syslog component.

I will assume you already have a disk added to vMA and you have created the appropriate mount point (If you are unsure how, do a search online). In this example, I have a 15GB partition in /vmasyslog that I will use as the new home for all my vilogger syslog files.

After you have made the edit to vMA.conf, you will need to restart vilogger daemon and you will need to use sudo and the service command.

Now, you can enable vilogger for your ESX and ESXi host and you should see all logs being redirected to this new partition instead of the default /var/log/vmware/*

Categories // Uncategorized Tags // /var/log, vma

Ghetto Reflections 2010

12.30.2010 by William Lam // 1 Comment

Looking back on 2010, it is hard to believe that virtuallyGhetto was created only 7 months ago. Instead of writing a long post, we thought we would share with you some of the highlights and favorite blog posts/scripts of 2010:

Here were the highlights for virtuallyGhetto in 2010:
May 31st - virtuallyGhetto says hello to the blogosphere
June 25th - virtuallyGhetto is part of the esteemed VMware Planet v12n feed
Sept 27th - virtuallyGhetto made the Top 25 VMware Bloggers List
Nov 19th - Veeam becomes first sponsor for virtuallyGhetto

Here were the top 10 blog posts of 2010 by page views:
Automating ESXi 4.1 Kickstart Tips & Tricks 9,914
ESXi 4.1 - Major Security Issue 4,564
Getting started with vMA 2,976
What is VMware vsish? 2,768
1200+ undocumented .vmx parameters 1,660
Automating vCloud Director and Oracle DB Installation 1,283
Script: Updated ghettoVCB and ghettoVCBg2 to Support vSphere 4.1 1,279
vMA 4.1 - Active Directory IntegrationTip 1,240
How to inject custom drivers into an ESXi 4.1 image using vibddi? 1,239
How to configure and use vMA's vi-fastpass with fpauth and adauth on vSphere 4.1 1,121

 

Here were the top 10 ghetto scripts of 2010 by page views:
ghettoVCB.sh 367,905
ghettoVCBg2.pl 66,683
vmwarevSphereHealthCheck.pl 62,861
ghettoShutdown.pl/upsVIShutdown.pl (DEPRECATED) 48,693
vmwareHealthCheck.pl 36,969
ghettoVCB-restore.sh 30,583
ghetto-esxi-linked-clones.sh 12,227
ghettoUPSHostShutdown.pl 7,820
vmwarevSphereSecurityHardeningReportCheck.pl 5,356
ghettoHostBackupManagement.pl 4,723

*Note: You may have noticed that the ghettoVCB VMTN document is currently inaccessible (displays "Forbidden" error). This is a known issue that was caused by the recent VMTN community upgrade by VMware. We apologize for any inconvenience this may have caused and we are hoping the issue will get resolved when VMware resumes after the holiday period. In the meanwhile, you can access the document via Google cache for the latest version of the script*

We also want to take this moment to thank our readers and the virtualization community for the support that you guys have given us through the comments on the blog, VMTN, linkage, twitter re-tweets, etc. There are two individuals that I would like to personally thank: Duncan Epping who has encouraged me on numerous occasions to start my own blog. In the end, it was the passion and dedication that Duncan put into his own blog to share with the community that really inspired me to start virtuallyGhetto. I would also like to thank Chris Wolf, who has been one of our first avid supporters of ghettoVCB and even today, he is still one of our largest advocate, providing honorable mentions even in his VMworld presentations!

We look forward to 2011 and hope to continue to provide great content and scripts to the VMware and virtualization community. We wish you happy holidays and a great New Year! See you all in 2011!

Categories // Uncategorized Tags // ghetto

  • « Previous Page
  • 1
  • …
  • 62
  • 63
  • 64
  • 65
  • 66
  • …
  • 74
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Crowdsourced Lab Hardware for ESXi 9.0 Dashboard 06/17/2025
  • Automating the vSAN Data Migration Pre-check using vSAN API 06/04/2025
  • VCF 9.0 Hardware Considerations 05/30/2025
  • VMware Flings is now available in Free Downloads of Broadcom Support Portal (BSP) 05/19/2025
  • VMUG Connect 2025 - Minimal VMware Cloud Foundation (VCF) 5.x in a Box  05/15/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025