WilliamLam.com

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 VMware ITBM (IT Business Management) configuration

by // 3 Comments

Over the years I have had the privilege to install the majority of VMware products in either my production environment when I was a customer or in my personal home lab for testing. While in the process of learning about the vCloud Automation Center 6.0 to automate the installation and configuration, I came across a VMware product that I was not very familiar with called VMware ITBM (IT Business Management Suite). ITBM integrates with vCloud Automation Center and provides your business with insights into various cost analysis and metrics for both your public and private clouds.

VMware ITBM is provided as a Virtual Appliance and given that it integrates with vCloud Automation Center which I just been deployed in my home lab, I thought I take a look to see how one could automate the initial configuration setup. After manually deploying ITBM, I found the setup through the VAMI to be pretty straight forward and one could easily automate this. There is a command-line utility called /usr/sbin/itfm-config that we will be using to register our ITBM instance to vCloud Automation Center. To help simplify the setup, I have created a simple shell script called configureITBM.sh that will automatically configure ITBM given three simple variable input:

  • VCAC_VA_SERVER - Hostname/IP of your vCAC VA Server
  • VCAC_SSO_PASSWORD - The SSO password
  • TIMEZONE  - Timezone

Here is a screenshot of executing the script on the ITBM Virtual Appliance:

To verify that the configuration was successful, we can login to the VAMI interface of ITBM by opening a browser to the hostname/IP Address:5480 and we should see under the Status section we are now connected to our vCloud Automation Center Server.

Once we have confirmed that ITBM has been successfully configured we can now head over to our vCloud Automation Center Server and we should see a new tab called Business Management.

As mentioned earlier, I have not used the ITBM product before but I do recall a demo that was given during an Alpha of vCloud Automation Center 6.0 and I was quite impressed with the amount of information and customization this tool provides for cost and operational analysis.

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.