Fun with Python and vSphere

How I learned about various automation tools via chasing down a small, infuriating problem

I have been working on a couple of really cool projects as of recent, partially to learn Python and be a better programmatic thinker, but also to try building something cool that could then be used by others for their own needs. I’m pretty close to announcing something on that latter end, but for now, I want to document my adventures with a variety of vCenter-specific tools that could come in handy.

The problem: Programmatically finding the vCenter GUID

I am a Global Solutions Architect at Zerto, which provides a data protection software suite that protects, among other things, vSphere VMs. The way that Zerto identifies resources within a vSphere environment is by concatenating the vCenter GUID, also referred to as the serverGuid, along with the moRef. It will look something like this:

d322b019-58d4-4d6f-9f8b-d28695a716c0.datastore-10 

The reason why Zerto does this, by the way, is because it’s very possible to have duplicate moRefs in any given environment, so the specific vCenter GUID was prepended as a way to uniquely identify the resource in question.

Getting the moRef of an object was easy and can be done via the Zerto API. Getting the vCenter GUID, however, is more of a challenge, especially from an automation perspective.

The GUID is not hard for an administrator to find, by the way. There are several ways to get this identifier:

  1. You can log into vCenter via the HTML5 client and navigate to the vCenter Server Appliance under Hosts and Clusters. In the URL that pops up, an objectId that looks like this will appear: urn:vmomi:VirtualMachine:vm-10:d322b019-58d4-4d6f-9f8b-d28695a716c0. This last part is the GUID!
  2. You can access it through the Managed Object Browser, or MOB. The MOB can be accessed through a web browser at https://ip.of.your.vcenter/mob. Under content.about you will find the instance UUID.
  3. You can get it through PowerCLI, the PowerShell-driven CLI utility for vSphere, with Get-VC -Server <hostname or IP address of vCenter> | fl
  4. You can also get it through the vCenter Server Appliance shell and by getting the contents of cat /etc/vmware-vpx/instance.cfg

The challenge that I had was that none of these solutions would work for me. I wanted to do everything natively in Python, without having to hard code it or make the admin do more work than absolutely necessary. So, what now?

pyVmomi and the VMware vSphere Automation SDK for Python

Spoiler alert: the way that I solved my problem was through pyVmomi. I was chasing the VMware vSphere Automation SDK for Python because that got me a lot of good info about what was running in vSphere, but it was a red herring!!

Both pyVmomi and the Automation SDK for Python are officially maintained and managed by VMware and they serve similar purposes — in fact, the Automation SDK requires pyVmomi be installed as a dependency.

The SDK has allowed me to do some pretty cool things like get a list of all tags or all VMs in a single vCenter inventory. Furthermore, there are vCenter-specific calls that you can run and get info on, like HA information. It was because of this that I was chasing my GUID problem through this library. It turns out, though, that all I needed to do was use pyVmomi and establish a SmartConnect session. From there, the session can be used very similarly to the MOB.

import ssl, requests

requests.packages.urllib3.disable_warnings()
ssl._create_default_https_context = ssl._create_unverified_context
context = ssl.create_default_context()
context.check_hostname = False
context.verify_mode = ssl.CERT_NONE
c = SmartConnect(host='192.168.20.2', user='administrator@lab.local', pwd='!super@secret@password$')
print(c.content.about.instanceUuid)
d322b019-58d4-4d6f-9f8b-d28695a716c0

Links and further reading

pyVmomi:

vSphere Automation SDK for Python

Other related links

Acknowledgement

Thank you to the great and powerful Ariel Sanchez Mora (https://twitter.com/arielsanchezmor/) for his guidance and help!

esxcli troubles – order matters!

As part of my efforts to renew my VCP5-DCV certification to the new and shiny VCP6-DCV (not to mention avoiding having to take another week-long class in order to qualify to do so), I have been spinning up a lab environment to mess around with. Like when I was studying for VCP5-DCV, I am using Mastering VMware vSphere 6 by Nick Marshall as my go-to guide.

In my lab, I deployed an instance of the vSphere Management Assistant (vMA) so that I can run vSphere CLI commands such as esxcli. The deployment of vMA went without any problems, but I was having a bunch of trouble getting it to authenticate with vCenter.

esxcli –server=192.168.1.85 –vihost=192.168.1.249 -username=administrator@vlab.local network ip interface list

(It may whine about not having a certificate in the credential store… if so, add the certificate.

/usr/lib/vmware-vcli/apps/general/credstore_admin.pl add -s vcenter.ip.address.here -t [certificate])

Then I started getting a weird authentication error…

authenticationproblem1

That’s weird. I tried the same password multiple times just to make sure I wasn’t typing it in wrong. No dice. I started looking online and found this thread:

https://community.spiceworks.com/topic/395441-vmware-cannot-complete-login-due-to-an-incorrect-username-or-password

Basically, this guy’s fix was to disconnect the host and reconnect it in vCenter. I tried that. It still failed.

Finally, I found the answer. https://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vcli.getstart.doc_50%2Fcli_jumpstart.3.4.html

After installation, run ESXCLI commands against a specific host by first specifying all dispatcher options. If the target server is a vCenter Server system, specify the target ESXi host before any ESXCLI namespaces, commands, and supported options.

It was purely a matter of what options in the command come first. I ran the command again like this:

authenticationproblem2

 

Tada! Order DOES matter to esxcli. The book example will not work as formatted.

Up next: scripting the nightly shutdown of the lab.

 

-ajs