WilliamLam.com

How to automate NTP configurations on the VCSA using the CLI

by // 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]

How to restart the ESXi management network via command-line?

by // 11 Comments

A great question that was brought up on Twitter yesterday by Andreas Peetz who asked the following:

Is there a way to restart the mgmt network in ESXi via a cmd line? You can do this from the DCUI, but I want a script! 

There are a variety of reasons why you would want to restart the Management Network on your ESXi host and usually it is related to troubleshooting or configurations such as renewing the DHCP lease on a particular VMkernel interface. For Andreas, it was renewing the DHCP lease and this is actually a use case I have heard from others before. Currently, the only way to restart the Management Network for your ESXi host is using the DCUI (Direct Console User Interface) either through the console using iLO/iDRAC/etc. or remotely over SSH.

Andreas' question is not a new one and I have heard this ask in the past. I have even inquired about it when I was a customer but was told it was not possible and had to use the DCUI. I was not really satisfied with the answer I provided to Andreas, so I decided to do a bit of digging myself and ping some engineers. Apparently this functionality is actually exposed through a legacy command-line utility called esxcfg-vmknic in the ESXi Shell as well as locally/remotely via the ESXCLI network namespace which is used to manage the VMkernel interface (Thanks to Andres for mentioning ESXCLI method).

There are two flags that this command supports which is to enable and disable a VMkernel interface. This is actually what the DCUI is doing when you ask it to restart the Management Network and is very similar to restarting a service on a UNIX/Linux system, it first shutdowns the service and then starts it back up. Given this information, if you wish to restart the Management Network of your ESXi host you can specify the name of the Management Network portgroup and execute the enable operation immediately after performing the disable operation.

To do this from the command-line, you would add a ; (semi-colon) between the two commands so they are executed one after another to ensure your VMkernel interface is enabled after you have disabled it. Here is an example of the command:

esxcli network ip interface set -e false -i vmk0; esxcli network ip interface set -e true -i vmk0

Automating vCloud Application Director (AppD) configuration

by // 1 Comment

After publishing my two-part series on automating vCAC 6.0 installation and configuration here and here, I received an interesting inquiry on how to automate vCloud Application Director (AppD) deployment and configuration. Given that I had a couple of days before winding down for the holidays and for my upcoming trip, I took my final challenge of 2013. The challenge with trying to automate AppD deployment, even though it is distributed as a Virtual Appliance is that it requires user interaction during the first bootup. A user must provide a valid AppD license key which then allows AppD service to start up and the user must also change both the root and admin account as part of the bootup process.

This is not ideal from an automation standpoint as it prevents anyone from automating the deployment and configuration of AppD. In my opinion, these configurations should have been part of the OVF properties which can then be specified during the deployment and allow for automated/unattended deployment of AppD. Since the setup was happening during the boot process, I opted for more of an out-of-the-box solution after spending a couple of minutes looking for a workaround.

The solution that I came up would require a "slight" modification to the startup scripts which is accomplished by initially mounting the VMDK of a newly deployed AppD Virtual Machine that has not been powered on. This can be done in one of two ways by either using a live-CD such as KNOPPIX or programmatically using the vSphere APIs. Once the VMDK has been mounted, you will need to rescan the guestOS to ensure the virtual disk is visible and then mount the 3rd partition of AppD Virtual Machine as seen in the screenshot below.

The following script /opt/vmware/etc/isv/firstboot is responsible for prompting for the license key as well as changing the passwords for the two user accounts. To allow the script to continue, we will need to comment out the following lines in the script 75-102 and 287-289 as seen in the screenshot below.

In addition to the change above, we will also need to the create the license file /home/darwin/tcserver/darwin/appd-license.properties that is normally generated by going through the regular process which must also contain a valid license key. This is required as it will prevent the AppD service from starting up properly. To help simplify the changes, I have created a simple shell script called prepvCloudAppD.sh which will automatically comment out the appropriate lines in the firstboot script as well as create the AppD license file. There are two variables you will need to specify before running the script:

  • APPD_LICENSE - The license key
  • APPD_VMDK_MOUNT_HOME - The mount home of the AppD filesystem (Default: /mnt)

Here is a screenshot of executing the script:

At this point we are now ready to power up our AppD Virtual Machine and you will notice that AppD no longer prompts the users for input.

Once AppD is up and running, you should change the default password for both the root and admin account as they are not very secure by default. The default password for the root account is "vmware" and the defualt password for admin account is "password". The admin password is not an OS account but an application account and this will need to be changed by using the darwin-cli. You can do this inside of a simple shell script or right on the command line by running the following command (be sure to replace it with the password of your choice):

APPD_ADMIN_PASS=VMware123
cat > /tmp/password << __APPD_PASSWORD__
${APPD_ADMIN_PASS}
${APPD_ADMIN_PASS}
__APPD_PASSWORD__

/usr/java/jre-vmware/bin/java -jar /home/darwin/tools/darwin-cli.jar login --serverUrl https://localhost:8443/darwin --username admin --password password\;change-user-password --username admin --currentUserPassword password\;logout < /tmp/password

The above commands will create a new file in /tmp/password which contains the password you wish to change the admin account to.

Then using the darwin-cli, we can now re-direct the file we just created and change the password without any user intervention which is great for automated configuration of AppD.

Finally, we can confirm everything was setup correctly by logging into the AppD interface by opening a browser to the following URL: https://[APPD-HOSTNAME]:8443/darwin and logging in using the admin account and password we changed earlier.