virtuallyGhetto

vsphere sdk for perl

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

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

[[email protected] ~]$ 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:

[[email protected] ~]$ sudo vi /etc/yum.repos.d/centos-base.repo

Add the following to the repo file:

5. Install GCC using yum:

[[email protected] ~]$ sudo yum -y --nogpgcheck install gcc.x86_64

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

[[email protected] ~]$ cd /usr/lib/vmware-vix/

[[email protected] 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

[[email protected] vmware-vix]$ cd vix-perl

[[email protected] vix-perl]$ sudo perl Makefile.PL
Writing Makefile for VMware::VixBinding

[[email protected] vix-perl]$ sudo make

[[email protected] 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:

[[email protected] ~]$ chmod +x installVIXPerl.sh

[[email protected] ~]$ 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:

[[email protected]]$ ./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:

New way of enabling and disabling services using vSphere 4.1

by 2 Comments

While checking out the PlanetV12n feed, I noticed a new video from David Davis about the new vSphere 4.1 Tech Support Mode. In the short video, David goes over the new method of enabling "hidden" unsupported Busybox Console, also known as Tech Support Mode. In the past, you had to be on the console of your ESXi host, type ALT+F1, and then "unsupported" to gain access. Once in, to enable remote SSH access or Remote Tech Support Mode, you had to edit /etc/inetd.conf and restart inetd service. This was pretty tedious if you needed access for a short period of time. In the video, David goes over the new method showing how it can be done using the DCUI and the old method is no longer required.

What surprised me after watching the video was that he did not mention the other method of enabling and disabling Tech Support Mode both local and remote. One issue I had with past releases of ESXi is that you could restart some services such as ntp or vmware-vpxa via the vSphere API, but others were just not available. In vSphere 4.1, VMware introduces a few new services around their Likewise Active Directory integration but also includes controlling both local and remote Tech Support Mode as well as DCUI itself.

These services can be enabled and disabled using the vSphere Client, here is a screenshot:

To enable or disable TSM, just click on the service and then click on options:

You will then have the option to configure the startup policy including enabling or disabling the service:

If you needed to perform this operation against one or two host, it is not that big of a deal. Though if you needed to enable remote Tech Support Mode (SSH access) across few dozen hosts, then can still be tedious. Luckily I wrote a script (hostServiceMangement.pl) last year that allowed you to enable and disable supported services using the vSphere API. Without any modifications, it supports vSphere 4.1 and can take advantage of the new services that are available for control.

Here is an example of listing the services on an ESXi 4.1 host:

Here is an example enabling remote Tech Support Mode:

Here is an example of disabling remote TSM:

The script can be executed on a host that has vCLI 4.1 installed or on vMA 4.1 and can bulk update a list of ESX/ESXi host or individual host. For more details, please check out the documentation for hostServiceManagement.pl.

Script – New vSphere Health Check Script 4.1.0

by Leave a Comment

Check out the latest update to the popular vSphere Health Check Script, now at v4.1.0, which supports the new release of vSphere 4.1 and is compatible with previous releases of vSphere.

Here is what's new in v4.1.0:

 For more details, please visit the documentation for vSphere Health Check Script.

Script – Automate VAAI Configurations in vSphere 4.1 (vaaiHWAccelerationMgmt.pl)

by Leave a Comment

With the release of vSphere 4.1, we finally get to see the first revision of the vStorage API for Array Integration (VAAI) features. This initial release provides the following SCSI driver primitives with VAAI supported storage arrays:

  • Write Same/Zero - Eliminating redundant and repetitive write commands, tells array to repeat via SCSI commands.
  • Full Fast/Copy - Leverage array to mass copy, snapshot and move blocks via SCSI commands.
  • Atomic Set and Test - Stop locking LUNs and start locking blocks.
  • Thin Provisioning Stun - Reporting array TP state to ESX.

The above definitions were taken off of an EMC presentation found here. VMware has also published a new VMware KB article regarding VAAI FAQ, take a look here at KB1021976.

Though these features are not specific to any one storage array vendor, the vendors themselves are required to implement these primitives within their array OS software for them to be available. If all prerequisites are met, and you have an ESX or ESXi host running on vSphere 4.1 and VAAI supported storage array, these new storage operations will now offload to the array versus running within the VMkernel.

However, if you do not have an array that supports VAAI, the new version of ESX and ESXi will still try to use these features. As I understand from an earlier discussion of VAAI, there is one additional operation that is performed and it's impact is supposed to be insignificant (please correct me if I'm wrong). Though if you would like to disable these VAAI features or would like to see the difference between a non-VAAI and VAAI operation, it is controlled with the following three advanced host configurations.

VMFS3.HardwareAcceleratedLocking - Atomic Test and Set
DataMover.HardwareAcceleratedMove - Full/Fast Copy
DataMover.HardwareAcceleratedInit - Write Same

By default, all three of these configurations are enabled with a default installation of vSphere 4.1. The following vSphere SDK for Perl script allows a user to enable or disable VAAI configuration on a set of hosts defined in an input file. The script allows you to connect to vCenter if your hosts are being managed by vCenter or directly to a specific ESX or ESXi host and provide the following parameters:

--hostlist = Lists of ESX(i) hosts to perform operation _IF_ they're being managed by vCenter (default is ALL hosts in vCenter)

--operation = Operation to perform (query|enable|disable)

Download: vaaiHWAccelerationMgmt.pl

Here is an example of the host input file:

[[email protected] scripts]$ cat hosts
esxi4-2.primp-industries.com
esxi4-3.primp-industries.com
Here is an example of querying for VAAI configurations:

Here is an example of disabling VAAI configurations:

Here is an example of disabling VAAI configurations:

For more information about vStorage APIs, take a look here.

Script – Automate Storage I/O Control in vSphere 4.1 (siocManagement.pl)

by 3 Comments

Storage I/O Control is a new feature of vSphere 4.1 which allows a user to define the QoS prioritization for the I/O activity on a single host or a cluster of hosts. SIOC supports only VMFS volumes and the latency threshold is configured on a per VMFS datastore.

Currently, the only method of configuring SIOC is using the vSphere Client while connected to your vCenter Server, which can be tedious if you manage more than 1 VMFS datastore:

The following vSphere SDK for Perl script allows a user to bulk update SIOC across your vSphere infrastructure based on an input file that consists of the name of the VMFS datastores and the latency thresholds to be configured. The script requires that you connect to your vCenter server and provide the following input parameters:

--datastore_inputfile = Is the name of the datastore input file which contains the name of your VMFS datastore and the latency value

--operation = There are four supported operations (query|enable|disable|update)

--vihost = Name of the ESX(i) host to perform the operation on (you only need to perform the operation on 1 host within a cluster and the changes are taken place across all hosts)

Download: siocManagement.pl

Here is an example of the datastore input file:

[[email protected] scripts]$ cat datastorelist
# datastorename;latency_value
# e.g.
# mydatastore1; 35
iSCSI-1;20
iSCSI-2;15
iSCSI-3;35
esxi4-3-local-storage-1;40

Note: The latency threshold must be between 10-100 ms. The default value when you enable SIOC is 30 ms,

Example of query operation:

Example of enable operation:

Example of disable operation:

Example of update operation:

Before attempting to make any changes, make sure you consult with your storage vendor.