WilliamLam.com

VMware API Related Acronyms

by // 3 Comments

Duncan Epping recently wrote an article about VMware related acronyms and shared with the community  the history and origins of some of the acronyms (e.g. ESX, GSX). After reading Duncan's article, I realized the acronym list primarily focused on product names and features. They did not cover some of the API related acronyms that I was curious about. If you have worked with the VMware APIs, SDKs or vmkernel, vmkwarning, hostd, vpxa, vpxd, etc. logs you may have noticed some of these acronyms and wondered what they actually stood for.

Here is my compiled list of VMware API related acronyms that I have been able to dig up by looking at these various locations:

DMS: Data Management Service
EAM: ESX Agent Manager
FDM: Fault Domain Manager
HMO: Host Managed Object
LS: License Service
MOB: Managed Object Browser
MOR: Managed Object Reference
OMS:  Operation Management Service
RBD: Rule Based Deployment (Auto Deploy)
SMS: Storage Monitoring Service
SPS:  Storage Policy Service
STOREMON: Storage Utilization Monitoring
VCI: (vci-integrity deals with VMware Update Manager, but no info on acronym)
VMAM: VM Application Monitoring
VMODL: VMware Managed Object Design Language
VMOMI: VMware Managed Object Management Interface
VOD: VPX Operational Dashboard
VOB/VOBD: VMkernel Observation 
VORB: VMOMI Object Request Broker Library/Application
VSM: vService Manager
VWS: VMware Web Services
WOE: Workflow Orchestration Engine

Disclaimer: These namespaces may change without notice as they are part of the internal VMware APIs. These are not publicly documented by VMware and should not be relied on other than for informative purposes.

There was also a recent VMTN question regarding the following two licensed features that is displayed for a given ESX(i) host and it was not clear what they were used for:

Here are the actual names and purposes:

dpvmotion: Direct Path vMotion (VM DirectPath I/O)
dvfilter: vNetwork Appliance API (dvfilter was an internal name)

The following are not VMware acronyms, but you may see these from time to time if you work with the vSphere API/SDKs:

API: Application Programming Interface
SDK: Software Developement Kit
WSDL: Web Services Definition Language
SOAP: Simple Object Access Protocol

I would also like to thank both Steve Jin and Reuben Stump from VMware in helping me track down the last few acronyms that I could not figure out.

If there are any additional acronyms that I missed or ones I should add to the list, please feel free to leave me a comment.

Upcoming vSphere.Next Features Hinted in vSphere 4.1 APIs?

by // 2 Comments

Back in December, I created a VTMN document - How to browse the internal vSphere APIs which shows you how to access some of the undocumented vSphere API properties and methods. This was done prior to vSphere 4.1 release, but by looking at the python SDK stubs located on an ESX or ESXi host, you can see some of the some of the upcoming features that would eventually be released in vSphere 4.1.

Here is a look at some of these features found in the vSphere 4.0 SDK stubs:

Features known:

API STRING FEATURE
vim.version.drs Distributed Resource Scheduler
vim.version.dvs Distributed Virtual Switch
vim.version.ft Fault Tolerance
vim.version.ipv6 IPv6

Features eventually known:

API STRING FEATURE
vim.version.iorm I/O Resource Management what is now known as Storage I/O Control or SIOC

Features unknown:

API STRING FEATURE
vim.version.fed Unknown - (Federation?)
vim.version.lc Unknown - (Related properties in API referenced Linked Clones)
vim.version.logan Unknown - (Related properties in API referenced MediaAnalysisManager
vim.version.policy Unknown - (Rrelated properties in API referenced PolicyManager
vim.version.svm Unknown - (Rrelated properties in API referenced svmVmxDiskCopy)
vim.version.uber Unknown

Now, looking at vSphere 4.1 SDK stubs, I noticed a slew of new "potential" features that VMware is or maybe working on:

vim.version.cvp - ?unknown? (Client Virtualization Platform? below are properties and methods associated with this feature)

  • SetDisplayTopologyModes
  • VirtualMachinePowerPolicyPowerMode
  • VirtualMachinePowerPolicyCpuMode
  • requestedReplicationCanBeDeferred
  • userAllowedToDeferReplication
  • policyCacheLifetime

vim.version.dev - ?device? (below are properties and methods associated with this feature which seem to be related to FCoE support with vSphere)

  • DiscoverFcoeHbas
  • FcoeConfigFcoeSpecification
  • removeFcoeHba
  • userAllowedToDeferReplication

vim.version.h20 - (unknown, but related properties in API referenced PropertyProviderManager)

  • InternalPropertyProviderManager

vim.version.hbr - ?unknown? (Host Based Replication? below are properties and methods associated with this feature)

  • hostBasedReplicationSupported

vim.version.vcp - ?unknown? (VM Component Protection? below are properties and methods associated with this feature)

  • ClusterVmComponentProtectionSettings
  • ClusterVmComponentProtectionSettingsFtVmReaction

What you see here are not just string text found in the SDK stubs, these features are actually implemented in the current release of vSphere 4.1. Though undocumented, if you can reverse engineer where these methods and properties are located, you can actually execute them.

Here is an example of executing discoverFcoeHbas method via the MOB which is part of the Host's StorageSystem:

I am no fortune teller, but I suspect we may see some of these features much sooner than later 😉

Automate Update Manager Operations using vSphere SDK for Perl + VIX + PowerCLI + PowerCLI VUM

by // Leave a Comment

I recently saw an interesting question on the VMTN developers forum asking about vSphere SDK for Perl and VUM API integrations. As it stands today, VMware has not publicly exposed or documented the VMware Update Manager APIs, though they have released a few PowerCLI VUM cmdlets for PowerCLI users. This is one feature, in my opinion, that PowerCLI has over the other vSphere SDKs. This is quite unfortunate, since automating VUM operations is something I have looked forward to and the process can be slow from clicking around in the GUI. I think VMware sometimes forget that the world does not run on Windows and that VMware != Windows.

I was hoping with the release of vSphere 4.1, the VUM APIs would finally be exposed as a standard web service like the vSphere API provided with proper SDKs for the various languages. My reply to the VMTN user was exactly this: this type of integration does not exist today. If you would like to automate VUM operations, you must use the PowerCLI VUM cmdlets. The follow-up comment was how one might integrate between vSphere SDK for Perl and PowerCLI VUM cmdlets. Initially, I did not recommend this but it could potentially work with some type of WMI call or hooks from some Perl modules. The solution might get a little messy and it would probably be faster to just set up the PowerCLI VUM cmdlets on a Windows host.

As I thought about the question later that evening, I realized that there is potentially another method if you wanted to use the vSphere SDK for Perl but utilize the PowerCLI VUM cmdlets. The following solution will demonstrate the use of vMA, vSphere SDK for Perl, VIX Perl API, PowerCLI and PowerCLI VUM cmdlets. VMware VIX is used for guest management for VMs running on a VMware hypervisor, whether it be Workstation, Fusion or ESX(i). There is a Perl SDK for the VIX API which I use to generate a PowerCLI script that is transferred directly into a Windows VM running both PowerCLI and PowerCLI VUM. This dynamic PowerCLI script will contain the host information and VUM baseline provided from the vSphere SDK for Perl script. The script will remediate the host and then it will be deleted by VIX. This configuration is not ideal, but if you wanted to automate some of the available VUM operations but continue to use your vSphere SDK for Perl scripts, then you can.

The dynamic PowerCLI script that is generated is the following:

Connect-VIServer -Server [vc-server] -Protocol https -User [vc-user] -Password [vc-password]
$vmhost = Get-VMHost [vi-host]
$baseline = Get-Baseline [host-baseline]
$baseline | Attach-Baseline -Entity $vmhost -Confirm:$false
$vmhost | Scan-Inventory
$baseline | Remediate-Inventory -Entity $vmhost -Confirm:$false

Note: This is just one example, you can easily customize the script to generate other VUM operations or more complex PowerCLI script. Once the operation is completed on the ESX(i) host, the script is deleted via VIX.

Before we get started, you will need to have a Windows VM that has both PowerCLI and PowerCLI VUM installed which resides in the same infrastructure as your VUM Server. You will also need to have VMware vMA available and installed with VMware VIX which will be documented down below.

1. Download VMware VIX 1.10

2. Transfer VMware-VIX-1.10.1-266898.x86_64.bundle installer to vMA

3. Install VIX:

VMware-VIX-1.10.1-266898.x86_64.bundle

================================================================

[vi-admin@kate ~]$ sudo sh VMware-VIX-1.10.1-266898.x86_64.bundle
Password:
Extracting VMware Installer...done.
You must accept the VMware VIX API End User License Agreement to
continue. Press Enter to proceed.
.....
The product is ready to be installed. Press Enter to begin
installation or Ctrl-C to cancel.
Installing VMware VIX API 1.10.1
Configuring...
[######################################################################] 100%
Installation was successful.

To complete the next section, you will need GCC to be installed which is not part of the default vMA installation. If you are using vMA 4.1, it is running CentOS and you can setup CentOS YUM repository. This will require that your vMA host can proxy out to internet or to specific site. I will document the changes that need to be made to talk to CentOS repository for package installs.

4. Create repository file:

[vi-admin@kate ~]$ sudo vi /etc/yum.repos.d/centos-base.repo

Add the following to the repo file:

5. Install GCC using yum:

[vi-admin@kate ~]$ sudo yum -y --nogpgcheck install gcc.x86_64

6. CD to vmware-vix directory and extract VIX Perl

[vi-admin@kate ~]$ cd /usr/lib/vmware-vix/

[vi-admin@kate vmware-vix]$ sudo tar -zxvf vix-perl.tar.gz
vix-perl/
vix-perl/vix.h
vix-perl/includeCheck.h
vix-perl/vm_basic_types.h
vix-perl/VixBinding.xs
vix-perl/VixBinding.pm
vix-perl/ModuleList
vix-perl/lib/
vix-perl/lib/API/
vix-perl/lib/API/API.pm
vix-perl/lib/API/Host.pm
vix-perl/lib/API/Job.pm
vix-perl/lib/API/VM.pm
vix-perl/lib/API/Snapshot.pm
vix-perl/lib/API/PropertyList.pm
vix-perl/lib/API/Constants.pm
vix-perl/lib/Simple.pm
vix-perl/Makefile.PL
vix-perl/typemap
vix-perl/ppport.h
vix-perl/README
vix-perl/samples/
vix-perl/samples/findhosttest.pl
vix-perl/samples/powertest.pl
vix-perl/samples/vmrun.pl
vix-perl/libvixAllProducts.so

7. Install VIX Perl

[vi-admin@kate vmware-vix]$ cd vix-perl

[vi-admin@kate vix-perl]$ sudo perl Makefile.PL
Writing Makefile for VMware::VixBinding

[vi-admin@kate vix-perl]$ sudo make

[vi-admin@kate vix-perl]$ sudo make install

If you did not want to go through all these manual steps after installing VIX, I actually wrote a quick shell script that will automate the configuration of the CentOS repository, GCC installation and extraction and installation of VIX Perl.

Download installVIXPerl.sh

Executing installVIXPerl.sh:

[vi-admin@kate ~]$ chmod +x installVIXPerl.sh

[vi-admin@kate ~]$ sudo ./installVIXPerl.sh

9. Download patch-host.pl script and transfer it to vMA

10. You will need to edit 4 variables defined within the script:

$psvm_username = Is the username to your Windows system running PowerCLI
$psvm_password = Is the password to your Windows system running PowerCLI
$powercli_bin = Is the full path to your powershell binary, if it is a default installation, you can leave this unchanged
$powercli_options = Is the path to vSphere PowerCLI psc file, you can also leave this as the default

Note: If you do decide to change either $powercli_bin or $powercli_options, make sure you add an extra "forward slash" which needs to be escaped in the Perl script.

The script requires you to connect to your vCenter server and provide the following parameters:

--vihost = Name of ESX(i) host to be patched

--baseline = Name of the VUM basline to attach

--psvm = Name of the Windows VM running both PowerCLI and PowerCLI VUM

Here is an example patching an ESXi host that is running on 4.0u2 and using the script to apply vSphere 4.1 baseline:

[vi-admin@kate]$ ./patch-host.pl --config --server reflex.primp-industries.com --username primp --vihost esxi4-3.primp-industries.com --psvm powerclivm --baseline vSphere4.1-Upgrade

Entering maintenance mode for esxi4-3.primp-industries.com
Successfully entered maintenance mode for esxi4-3.primp-industries.com
Guest login successfully!
Copy patch-host-esxi4-3.primp-industries.com-22174.ps1 to guest successfully!
PowerCLI/VUM script executed successfully!
Script removed successfully!
Successfully patched esxi4-3.primp-industries.com using VUM baseline: vSphere4.1-Upgrade

One thing I did notice, after the script is transferred to the Windows VM, it takes about 15-20 seconds before the script executes. I am not exactly sure why this occurs, as this does not happen when running the PowerCLI script logged into the VM. This may be due to the way VIX is executing the script within the guest.

The following resources were used in creating this script: