WilliamLam.com

Do I need to install both the vSphere CLI & vSphere SDK for Perl?

by // 1 Comment

I received this question from one of our TAMs (Technical Account Managers) last week asking what is the difference between the vSphere CLI and the vSphere SDK for Perl and whether you need to install both of them. The simple answer is there is no difference, but why do we have two packages then? Well, this was probably due to how the vSphere SDK for Perl and the vCLI was initially introduced and was distributed in two separate packages.

Starting with the vSphere SDK for Perl 4.0, both the SDK packages and the vCLI commands have been combined together. However, it looks like both packages are still being produced as part of the automated build process and this will be consolidated in a single distribution in a future release. Going forward, you can just download the vSphere CLI which is always tied to a vSphere release and you will be ensured that is fully compatible with the latest release.

For more details behind each of the packages, you can take a look at the quick summary below:

vSphere SDK for Perl

The vSphere SDK for Perl is just a client-side Perl framework that provides administrators with a scripting interface to the vSphere API. As part of the SDK (Software Development Kit) it also provides a variety of sample scripts.

vSphere CLI

The vSphere CLI or the vCLI for short is just a set of command-line scripts that implements a sub-set of the functionality from the vSphere API. These scripts include the vicfg-* commands which are remote version of the legacy esxcfg-* commands, as well as ESXCLI, vmkfstools and resxtop commands that can also be run remotely. Most importantly, the vicfg-* commands are built on top of the vSphere SDK for Perl and this is one of the reasons you need to have the vSphere SDK for Perl installed if you wish to use the vCLI commands.

Automate Enabling VM Storage Profiles Capability in vSphere

by // 1 Comment

I recently had to rebuild one of my lab environments that consisted of a vCenter Server and several ESXi hosts and one of the capabilities I required was VM Storage Profiles. In a brand new vSphere environment, VM Storage Profiles is disabled by default, presumably due to licensing as this feature is not available in every SKU. To enable VM Storage Profiles, you will need to connect to your vCenter Server using either the vSphere Web Client or the legacy vSphere C# Client as seen in the screenshot below.

Another way of enabling the VM Storage Profiles feature is through an automated fashion using the vSphere APIs where this functionality is exposed.

Note: To manage and consume VM Storage Profiles, you will still need to use the vSphere Web Client or vSphere C# Client as the APIs for this functionality is not yet available.

VM Storage Profiles is enabled on a per vSphere Cluster basis and there is a boolean property called spbmEnabled which determines whether this feature is enabled or disabled. To update this property, you will need to use the ReconfigureComputeResource_Task method.

Here is are two examples of implementing the API both in a PowerCLI script as well as a vSphere SDK for Perl script:

PowerCLI:

In my lab environment, I have a vSphere Cluster called "Cluster" and you can use PowerCLI to check whether VM Storage Profiles is enabled or not by running this command (replace Cluster with the name of your vSphere Cluster):

(Get-Cluster -Name Cluster).extensionData.ConfigurationEx.SpbmEnabled

To enable VM Storage Profiles, you can then call the Enable-StorageProfile function along with the name of the vSphere Cluster which is just called "Cluster":

 

vSphere SDK for Perl:

To enable VM Storage Profiles using the vSphere SDK for Perl, I wrote a quick script called storageProfileMgmt.pl which allows you to query whether a vSphere Cluster has VM Storage Profiles as well as enabling and disabling the feature. Here is a screenshot demonstrating how the script works:

Does ESXi Support DDNS (Dynamic DNS)?

by // 5 Comments

An interesting feature request that was raised internally was for ESXi to support DDNS (Dynamic DNS) which allows a host client to update it's DNS record when using a DHCP Server. In most environments, to assign a hostname from DHCP, a DHCP reservation is used and this is maintained by the DHCP Server versus DDNS, where it is maintained by the client. Thanks to my colleague Eric Wager who did some quick research and found that ESXi does in fact supports DDNS and has been since ESXi 5.0.

I have not worked with DDNS much in the past and I have only seen it used for free/paid online services targeted at consumers to provide a well known address when their public IP Address changes frequently as with most ISPs. If your DHCP Server supports DDNS, this can be a handy feature to have, especially as you add new hosts you no longer have to manually create individual DNS record before hand and great for a lab environment. I did a big more digging to have a better understanding of how DDNS works with ESXi.

To enable support for DDNS on your ESXi host, you just need to set the hostname for the following ESXi Advanced Setting:

/Misc/PreferredHostName

You can do this in a variety of ways using either the vSphere Web/C# Client or using the command-line with ESXCLI.

Here is the syntax for the command:

esxcli system settings advanced set -o /Misc/PreferredHostName -s vesxi04.primp-industries.com

Once you have configured the setting, for the changes to go into effect, you will need to restart the management network. The easiest way to do this is via DCUI which you can run remotely by just typing dcui if you have an SSH session to your ESXi host. If you are using scripted install such as Kickstart, this can easily be automated as part of the post-install and upon first boot, DDNS will be enabled and configured with the proper hostname.

To test this in my lab environment, before enabling DDNS, I performed a reverse lookup of the assigned IP Address of my ESXi host from my DHCP server. In this example, the host received the address 192.168.1.135.

As you can see from the screenshot, a hostname could not be resolved as I would expect. After our changes, if we perform the reverse lookup again, we should now see the hostname that we had configured.

Another useful tidbit is the DHCP Client on ESXi is an ISC BIND implementation and this means if you require advanced things such as authentication keys, you can configured these options in /etc/dhclient-vmkX.conf where X is the specific VMkernel interface. For most deployments, you should not have to edit this file. Also if you want to prevent your DHCP Server from overriding the hostname of your ESXi host, you can add the following entry to the dhclient-vmkX.conf configuration file:

interface vmk0 {
   supersede host-name "vesxi04.primp-industries.com";
}

Just when I thought I knew about all the awesome features ESXi offers, it is a nice surprise to learn about another one!