VMware scripting

Helpful VKernel SearchMyVM queries for use in VI3 environments

In my opinion, VKernel’s SearchMyVM virtual appliance (VA) has to be one of the most useful free virtualization management tools. I have found myself using it quite frequently to get information about my environment. I mentioned its release over on SearchServerVirtualization, and here I want to share some common queries I’ve used that you may want to hold onto for frequent use, and how they can help you:

vm.cdroms.connected=true – Running this query will tell you which VMs have connected virtual optical media, which can inhibit VMotion on the guest.

vm.toolsStatus=toolsNotInstalled,toolsNotRunning,toolsOld – All VMs that have VMware tools status of everything but OK.

cluster.haFailoverLevel – Lists all cluster’s HA Failover level. This is an easy way to spot check for consistent settings.

cluster.drsEnabled – Shows clusters that have DRS enabled. This one goes hand and hand with the HA settings to ensure that they are enabled across all environments as expected.

vm.hostName:servername – Gives the quick query of a guest’s hostname that is like servername, this is incredibly handy if you need to quickly find what resource pool, cluster, or datacenter a virtual machine is located.

file.datastore.name:storage – This query shows VMs located on a datastore that contains the string “storage”. By default, local datastores of ESX are named servername:storage1 for local VMFS volumes. Likewise, if your development or otherwise low-priority storage has the string ‘dev’ in it, you can replace storage with ‘dev’ and see the inventory of VMs that reside on that class of LUN.

vm.cpuLimit=-1 – This query shows the VMs that currently do not have a CPU limit, meaning, they can consume the maximum amount of GHz available to the guest.

datastore.freeSpace – This query displays the free space of every LUN available to every datacenter in the VI3 environment.

The SearchMyVM VA enables administrators to quickly pull in information from across their VI3 environment. This beta release is available for free download from the VKernel website.

VMware working on patch for ESXi API exploit

Although VMware’s ESXi hypervisor is free under the VMware Infrastructure (VI) base license, it’s not without limitations.

Only some of the application programming interface (API) method calls that are typically shipped with the VI SDK are available. It’s impossible, for example, to power on and off a virtual machine directly with Java or C#, the VI Toolkit (for Windows), the VI Perl Toolkit, or any other scripting toolkit or programming language that leverages the VI SDK. Full functionality is restricted to the VI client. I believe that this is VMware’s attempt to prevent third parties from developing management solutions for ESXi and selling them at lower cost than VMware’s VirtualCenter.

Despite these restrictions, I recently discovered a workaround that allows full access to the API. The method to circumvent VMware’s lockdowns will not be discussed here because it is unintentional and violates section 3.3 part 4 of the ESXi EULA:

You may not … create, develop, license, install, use, or deploy third party software or services to circumvent, enable, modify or provide access, permissions or rights which violate the technical restrictions of the Software.

VMware has been notified and is currently working on a patch to resolve this issue. Remember that in the interim, this method or any other means used to gain full access to the API in the free version of ESXi violates the EULA and should not be used.

That said, it’s still pretty cool

The VMware VI Client - Why is it Windows only?

Have you ever wondered why VMware’s VI client is Windows only? The most obvious reason is that it is written in C# using the .NET framework. However, the client could easily be written in Python or Java or some other OS agnostic language. So why Windows only? There are in fact two reasons the VI client is Windows only, let’s take a look at them.

“I’ll be your Huckleberry”

VMware apparently uses a C library called “TomSawyer” to handle the task of graphing performance output. Digging into a disassembled VI client, you can see where the Interop assembly is used and what it is used for. Using the Microsoft OLE/COM viewer to peer directly into TomSawyer’s library certain functions and strings like “GridColumnObject” and “TSEFlowChartType” give away the library’s purpose. I cannot think of a reason to marshal a library that graphs datasets unless VMware thought .NET was not up to the task of plotting data. However, the performance graphs displayed in a VI client take so long to initialize anyway that I do not think anyone one have noticed. As Barney on HIMYM says, “JIT up!”

QuickMKS

Sorry, I did not have a witty title for this section The other reason that the VI client is Windows only appears to be the library that it uses for the console view. The MKS (mouse, keyboard, sound) library is what the VI client marshals when it creates the console connection directly to the VM. Notice the absence of a V? I do too. Although the library’s name does not explicitly state that it is responsible for video, the functions inside of it, FullScreen, SetFullScreen, SetGuestSize, etc., seem to indicate that it *is* the responsible library.

Anything else?

TomSawyer can certainly be ported to run natively in .NET or another language (it does already in fact have a Java version), but QuickMKS may be a bit more difficult. It almost certainly relies on native OS calls that are most likely quite difficult to get working on other systems. However, if VMware would be so kind to send the source code my way, I’d sure like to try!