WilliamLam.com

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

Automating Log Insight 2.0 configurations

04.21.2014 by William Lam // Leave a Comment

Last week I had a chance to deploy the latest release of vCenter Log Insight 2.0 (currently in public beta) in my lab to give it a spin. I must say, I am very impressed with the slick new UI and some of the new capabilities like the scale-out and high availability feature.

automate-log-insight-2-0-configuration-0
The actual deployment of the Virtual Appliance is pretty straight forward and the only thing I would mention when selecting the OVF Deployment Size is that the default "Small" option is not the smallest configuration possible. There is actually an "Extra Small" option that can be selected in the drop-down menu which is targeted for POCs and lab evaluations. This will help with minimizing the resource constraints for lab environments.

Something that I am always interested in when evaluating a new solution is to see how easy an automated and unattended configuration is. With the help of some of the Log Insight folks, I was able to create the following shell script which will perform a basic configuration of Log Insight which includes the backend database, admin password and NTP servers:

#!/bin/bash
# William Lam
# www.virtuallyghetto.com

LOG_INSIGHT_ADMIN_PASSWORD=vmware123
LOG_INSIGHT_DB_PASSWORD=vmware123
NTP_SERVERS="0.pool.ntp.org, 1.pool.ntp.org"

### DO NOT EDIT BEYOND HERE ###

LOG_INSIGHT_CONFIG_DIR=/storage/core/loginsight/config
NODE_TOKEN_FILE=node-token
LOG_INSIGHT_CONFIG_FILE=loginsight-config.xml#1
NODE_UUID=$(uuidgen)

echo "Creating ${LOG_INSIGHT_CONFIG_DIR} .."
[ ! -e ${LOG_INSIGHT_CONFIG_DIR} ] && mkdir -p ${LOG_INSIGHT_CONFIG_DIR}

echo "Generating Log Insight Node UUID ..."
echo ${NODE_UUID} > ${LOG_INSIGHT_CONFIG_DIR}/${NODE_TOKEN_FILE}

echo "Generating Log Insight Configuration file ..."
cat > ${LOG_INSIGHT_CONFIG_DIR}/${LOG_INSIGHT_CONFIG_FILE} << __LOG_INSIGHT__
<config>
<version>
<strata-version value="2.0.1-1734312.UNSTABLE" release-name="Nightly"/>
</version>
<distributed overwrite-children="true">
<daemon port="16520" token="${NODE_UUID}">
<service-group name="standalone"/>
</daemon>
</distributed>
<database>
<password value="${LOG_INSIGHT_DB_PASSWORD}"/>
<port value="12543"/>
</database>
<ntp>
<ntp-servers value="${NTP_SERVERS}"/>
</ntp>
</config>
__LOG_INSIGHT__

echo "Restarting Log Insight ..."
service loginsight restart

echo "Setting Admin password ..."
ADMINPASSWORD=${LOG_INSIGHT_ADMIN_PASSWORD} /opt/vmware/bin/li-reset-admin-passwd.sh

You will need to edit the following variables within the script:

  • LOG_INSIGHT_ADMIN_PASSWORD
  • LOG_INSIGHT_DB_PASSWORD
  • NTP_SERVERS

Here is an example of running the script against a newly deployed Log Insight system:

automate-log-insight-2-0-configuration-1
The above is just an example of what could be automated for Log Insight. If you take a look at the Configuration section of Log Insight, there are many more options.

automate-log-insight-2-0-configuration-2
If you decide you want to automate additional configurations. The way you would accomplish this is to first configure everything from the Log Insight configuration UI. Once you are happy with the configuration, SSH into your Log Insight system. In /storage/core/loginsight/config you will find a couple of configuration files loginsight-config.xml#X with a numeric number at the end. If you take a look at the file with the highest number, it will contain the latest changes to Log Insight and the configurations you made using the UI. You can then take that file and update the script to automate the other configuration options.

Categories // Automation Tags // vCenter Log Insight

How to automate NTP configurations on the VCSA using the CLI

02.03.2014 by William Lam // Leave a Comment

NTP configurations should be a mandatory setting for everyone, regardless of whether we are talking about VMware products or general infrastructure software. It is just as critical as having proper DNS configured and can cause a whole slew of issues if not configured or setup properly. A question that was raised internally a couple of days back was around automating NTP configurations on the VCSA (vCenter Server Appliance) which is normally performed through the VAMI web interface as seen in the screenshot below.

Instead of using the VAMI UI, the user was interested in automating it through the command-line and wondered if this was possible. This is definitely possible among other VAMI operations by leveraging the vpxd_servicecfg utility and there are a couple of options when configuring NTP on a VCSA 5.5 system.

The option that most of you will probably using is to configure a list of NTP servers (comma separated). To do so, you can run the following command (replace the NTP server with your own):

/usr/sbin/vpxd_servicecfg timesync write ntp '172.30.0.100' ''

This command should have a return code of 0, else there maybe an issue connecting to your time source from the VCSA. You can also confirm the operation was successful or query the current configuration by running the following command:

/usr/sbin/vpxd_servicecfg timesync read

If you wish to synchronize your time with the underlying ESXi host through VMware Tools, then you can run the following command:

/usr/sbin/vpxd_servicecfg timesync write tools '' ''

Finally, if you wish to disable time synchronization on the VCSA for whatever reason, you can do so by running this command:

/usr/sbin/vpxd_servicecfg timesync write none '' ''

Note: If the VCSA is joined to an Active Directory domain, then the time synchronization is provided by your Active Directory server and no additional configurations are required.

Once you have configured your NTP servers, you should can also manually force a sync to ensure the current date/time is correct by running the following command:

sntp -P no -r [NTP-SERVER]

Categories // Automation, VCSA Tags // ntp, VCSA, vcva, vpxd_servicecfg, vSphere 5.5

How to verify SSO Multi-Master Replication is properly configured & working?

12.12.2013 by William Lam // Leave a Comment

I wrote an article yesterday demonstrating a hybrid configuration using the new SSO Multi-Master Replication in vSphere 5.5 between a vCenter Server for Windows & a VCSA (vCenter Server Appliance). The process itself is pretty straight forward and I even created a script which will automate the entire configuration. However, other than some text being shown at the end of the script stating that MMR (Multi-Master Replication) being successfully setup; how do you actually confirm MMR is properly configured & working when adding additional SSO instances?

This was something I was actually pondering about since the process was just too "easy" and pretty much seamless as it should be from a users perspective. In speaking with engineering, I came to learn that vmdird (VMware Directory Service) just leverages the LDAP standard for MMR. This means we can use any LDAP browser to connect to vmdird and view its current configuration.

Disclaimer: Please take extreme caution when viewing the vmdird database, this is primary for educational purposes. You should not be making any changes while in the database else you can negatively impact your environment.

In this example, we will be leveraging the free open source LDAP browser JXexplorer which can be run from variety of operating systems including Windows and Mac OS X. We will use JXexplorer to verify replication between our source (vCenter Server on Windows) is properly configured with our target (VCSA), you can also do this for a Windows to Windows vCenter Server deployment. We will also verify that replication itself is working by going through an example of creating an object in the source system and then verifying it has been successfully replicated to the target system.

Step 1 - Download and install JXplorer on your desktop, it does not have to run on the vCenter Server itself as we can remotely connect to the vmdird.

Step 2 - Create a new LDAP connection for your source vCenter Server on Windows using the following configuration below:

Protocol: LDAPv3
Port: 11711
Base DN: dc=vsphere,dc=local
Level: User + Password
User DN: cn=Administrator,cn=Users,dc=vsphere,dc=local

If everything was entered correctly, you should now be able to connect to the vmdird database.

Step 3 - To confirm MMR has been successfully configured between your source and target SSO Servers, you can expand the inventory to local->vsphere->Configuration->Sites->Servers. Here you should see the list of SSO Servers participating in a specific site. If you expand each server, you should see a replication agreement between the source and target of each server, this means everything is configured correctly.

In the example I had in my last blog post vcenter55-3.primp-industries.com is my vCenter Server for Windows and vcenter55-2.primp-industries.com is my VCSA. We can clearly see the replication agreements between our two systems and everything looks good.

Step 4 - To check whether MMR is working, a simple test is to create a user in vsphere.local domain using the vSphere Web Client and then compare the Users database between our source and target vmdird databases. To do so, you can open up two JXexplorer sessions, one connecting to the source vmdird and the other connecting to the destination vmdird.

MMR takes ~30sec to perform the replication and in the example above, I created a user called "wlam" on my source site and then I was able to refresh my destination system and the new user has automatically been replicated.

I really like the new SSO architecture and has really simplified SSO installation and configuration by a factor of 1000x. The built-in multi-master replication is completely transparent to the end user and this is the type of user experience our customers have come to expect of VMware. Big kudos to the SSO Engineering/Product team for all their hard work! There is still a lot of work being done to further enhance the overall install/upgrade experience and hopefully we will get to see some of these benefits in the very near future.

Categories // Automation, VCSA, vSphere Tags // ldap, multi-master replication, sso, VCSA, vcva, vdcpromo, vSphere 5.5

  • « Previous Page
  • 1
  • …
  • 206
  • 207
  • 208
  • 209
  • 210
  • …
  • 224
  • 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

  • Ultimate Lab Resource for VCF 9.0 06/25/2025
  • VMware Cloud Foundation (VCF) on ASUS NUC 15 Pro (Cyber Canyon) 06/25/2025
  • VMware Cloud Foundation (VCF) on Minisforum MS-A2 06/25/2025
  • VCF 9.0 Offline Depot using Synology 06/25/2025
  • Deploying VCF 9.0 on a single ESXi host? 06/24/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

 

Loading Comments...