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.
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:
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.
The vSphere MOB (Managed Object Browser) is not a well known tool and unless you are a developer, you probably do not know of its existence. The simplest way to describe the vSphere MOB is that it is a debugging tool to graphical visualize all entities within the vSphere API through a web browser. It is often used to better understand the vSphere API/inventory and aide in developing your own vSphere application or script. For a detailed deep dive of the vSphere inventory, check out Steve Jin's post here.
The vSphere MOB can be reached by pointing your web browser to either an ESX(i) or vCenter host followed by the path "/mob". You will be prompted for credentials as you normally would prior to gaining access to the MOB.
The vSphere MOB may not always be the easiest to navigate. Understanding the vSphere inventory structure is definitely helpful, otherwise it can be very confusing to users. With the release of vSphere 4.1, there are two major changes in the MOB that can help make the navigation easier for developers.
Previous to vSphere 4.1, the MOB would display managed entities using their Managed Object IDs (MoRef ID) as a way to uniquely identify these objects. This made it very difficult for developers to identify the specific object you are viewing without having to dig further.
In vSphere 4.1, the MOB provides both the MoRef ID and the translated the names of the managed entities.
The vSphere MOB not only displays information about the managed entities but also provides a way to interact with the system. It does this by listing the available API methods for each managed entity at the bottom of the page and can be executed by providing the correct input parameters. The issue arises when trying to execute methods which requires complex input that require more than a simple string or integer value. The format of the input is XML-based and it can be challenging to generate the correct format, especially without any examples.
In the new version of the MOB, you are now presented with an XML template of the required parameters which can then be filled out to execute the method.
The following example will demonstrate the change of an ESXi advanced configuration value for configuring a syslog server:
Once you have filled in the required parameters, you will need to click on the "Invoke Method" to execute the specific method.
Here we verify the advanced configuration key "Syslog.Remote.Hostname" has been changed and is set to our new syslog server.
I think these two changes will make it easier for developers to navigate the vSphere MOB and assist with understanding the vSphere API and it's managed entities.
In this final three part esxcli series, I will show you how to automate esxcli operations in a Windows environment using PowerShell. There was a recent question on the VMTN forums regarding this very topic. As a simple solution to the problem, a community member provided a snippet of PowerShell code. Of course the snippet of PowerShell code originated from the great PowerCLI Master - Luc Dekens.
I have slightly modified the original version of the script as I am not a fan of hard coding passwords within a script. This version of the script requires plink which is a command-line interface to the free Windows SSH PuTTY back end. The script performs an SSH connection to either an ESX or ESXi host to run esxcli command locally, with the specified parameters as you would if you were on the Service Console, or the unsupported Busybox console.
Copy the snippet of code below and create a new script called esxcli-automation1.ps1 and replace all the variables matching your environment including the $cmd which specifies the exact esxcli command you are running on the remote host.
esxcli-automation1.ps1
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
$User = "root" $Computer = "esxi4-1.primp-industries.com" #prompt user for password $passwordInput = Read-Host -AsSecureString:$true "Please enter password for $Computer" #convert secure password to normal string $Ptr = [System.Runtime.InteropServices.Marshal]::SecureStringToCoTaskMemUnicode($passwordInput) $Password = [System.Runtime.InteropServices.Marshal]::PtrToStringUni($Ptr) [System.Runtime.InteropServices.Marshal]::ZeroFreeCoTaskMemUnicode($Ptr) $plink = "C:\plink.exe" $esxcli = "esxcli" $plinkoptions = " -v -batch -pw '$Password'" $cmd = 'nmp device list' $remoteCommand = $esxcli + " " + '"' + $cmd + '"' $command = $plink + " " + $plinkoptions + " " + $User + "@" + $computer + " " + $remoteCommand Invoke-Expression -command $command |
Here is a sample execution listing devices:
There are a few issues with this script:
In a perfect world, the esxcli API would be properly exposed and integrated into the vSphere API. PowerCLI and other vSphere SDKs would be able to automate these configurations without this hack, but unfortunately this is not the case. However, we can leverage the esxcli utility that is bundled up with the vCLI which can be installed on either a Linux or Windows platform.
With this information, I decided to write my own PowerShell script (yes you heard right, it was slightly difficult without knowing the syntax and format) matching the capabilities similar to that of the vSphere SDK for Perl implementation running on vMA. So here is the second revision of the script called esxcli-automation2.ps1:
esxcli-automation2.ps1
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
$Username = "root" $esxcli = "C:\Program Files\VMware\VMware vSphere CLI\bin\esxcli.exe" #$Params = "swiscsi nic list -d vmhba33" #list of ESX and ESXi host to perform operation against $vihosts = @("esxi4-1.primp-industries.com","esxi4-3.primp-industries.com") #prompt user for password $passwordInput = Read-Host -AsSecureString:$true "Please enter your common password for hosts" #convert secure password to normal string $Ptr = [System.Runtime.InteropServices.Marshal]::SecureStringToCoTaskMemUnicode($passwordInput) $Password = [System.Runtime.InteropServices.Marshal]::PtrToStringUni($Ptr) [System.Runtime.InteropServices.Marshal]::ZeroFreeCoTaskMemUnicode($Ptr) #loop through array of hosts for($i = 0; $i -le $vihosts.length -1; $i++) { write-Host Executing operation on $vihosts[$i] #could not find a way to store the params in a variable you must #insert esxcli parameters at the very end of the statement below & $esxcli --server $vihosts[$i] --username $Username --password $Password swiscsi nic list -d vmhba33 } |
Note: PowerCLI is not required, just PowerShell.
This new version of the script allows you specify a list of ESX or ESXi host to perform a common esxcli operation. The script also prompts for the password as the previous script, so you do not have to hard code the password to the host. You will need to update the script with the path to the plink.exe and the list of hosts you want to perform the operation against.
Here is an example of verifying iSCSI multipathing configuration against two hosts (1 ESX and 1 ESXi) without the use of SSH:
As you can see, you can easily integrate this with other existing PowerCLI scripts that perform configuration changes across a given set of host(s). Until VMware provides access to the esxcli APIs, these are some of the methods/hacks that need to be implemented when automating configuration changes using esxcli.
Here are some PowerShell references that were used in creating the two scripts:
In the previous article, esxcli Part1, we discussed what esxcli is and what it can be used for. In this article, we will show you how you can automate and perform a common esxcli operation against a set of ESX and/or ESXi hosts using vMA. As mentioned in the previous article, esxcli needs to be executed against a specific host, it is not vCenter aware and cannot connect to vCenter to perform an operation against a host.
One of the pre-requisites before starting is that all ESX and ESXi hosts need to be managed by vMA and accessible using vi-fastpass authentication. Please refer to the vMA documentation on configuring this on vMA.
Download:esxcli-automation.pl
The following script is based off of useVIFastpassOnvMAToRunPerlScriptWithoutClearTextPassword.pl. The modified script utilizes the vi-fastpass library to properly access a set of target(s) and performs the specified esxcli operation without having to provide credentials to each and every host.
The following example will demonstrate iSCSI multipath configuration on two hosts using the method described by Duncan Epping in this article.
1) Create a file containing the list host to perform the operations against:
[[email protected] ]$ cat hosts
esxi4-1.primp-industries.com
esxi4-3.primp-industries.com
2. Run the script with the specific esxcli parameters as you would normally by passing it into the --cmd_option argument (double quote the arguments):
Binding iSCSI interface to vmk0
[[email protected] ]$ ./esxcli-automation.pl --hostlist hosts --cmd_option "swiscsi nic add -n vmk0 -d vmhba33"
Executing script on "esxi4-1.primp-industries.com" ...
Executing script on "esxi4-3.primp-industries.com" ...
Binding iSCSI interface to vmk1
[[email protected] ]$ ./esxcli-automation.pl --hostlist hosts --cmd_option "swiscsi nic add -n vmk1 -d vmhba33"
Executing script on "esxi4-1.primp-industries.com" ...
Executing script on "esxi4-3.primp-industries.com" ...
3. Verify iSCSI multipathing has been properly configured:
[[email protected] ]$ ./esxcli-automation.pl --hostlist hosts --cmd_option "swiscsi nic list -d vmhba33"
Executing script on "esxi4-1.primp-industries.com" ...
vmk0
pNic name: vmnic0
ipv4 address: 172.30.0.183
ipv4 net mask: 255.255.255.0
ipv6 addresses:
mac address: 00:50:56:92:69:7a
mtu: 1500
toe: false
tso: true
tcp checksum: false
vlan: true
link connected: true
ethernet speed: 1000
packets received: 167051261
packets sent: 232132
NIC driver: e1000
driver version: 8.0.3.1-NAPI
firmware version: N/A
vmk1
pNic name: vmnic1
ipv4 address: 172.30.0.184
ipv4 net mask: 255.255.255.0
ipv6 addresses:
mac address: 00:50:56:92:68:6c
mtu: 1500
toe: false
tso: true
tcp checksum: false
vlan: true
link connected: true
ethernet speed: 1000
packets received: 145924
packets sent: 54502
NIC driver: e1000
driver version: 8.0.3.1-NAPI
firmware version: N/A
Executing script on "esxi4-3.primp-industries.com" ...
vmk0
pNic name: vmnic0
ipv4 address: 172.30.0.233
ipv4 net mask: 255.255.255.0
ipv6 addresses:
mac address: 00:50:56:92:33:95
mtu: 1500
toe: false
tso: true
tcp checksum: false
vlan: true
link connected: true
ethernet speed: 1000
packets received: 138535
packets sent: 8026
NIC driver: e1000
driver version: 8.0.3.1-NAPI
firmware version: N/A
vmk1
pNic name: vmnic1
ipv4 address: 172.30.0.234
ipv4 net mask: 255.255.255.0
ipv6 addresses:
mac address: 00:50:56:92:27:65
mtu: 1500
toe: false
tso: true
tcp checksum: false
vlan: true
link connected: true
ethernet speed: 1000
packets received: 145924
packets sent: 112
NIC driver: e1000
driver version: 8.0.3.1-NAPI
firmware version: N/A
Now you will be able to automate any of the supported esxcli operations against multiple hosts!
In Part3, we will take a look at automating esxcli operations in a Windows environment using Powershell.
Step 1. Visit the vSphere SDK for Perl Home Page
You will find latest Downloads, Reference Documentation and Community Discussions and links to resources.
Step 2. Become familiar with vSphere SDK for Perl Resources:
Step 3. Explore new ways of managing your vSphere Platform using the remote CLI
Additional utilities bundled with vCLI/RCLI installation
Step 4. Develop and create your own scripts and utlities using the vSphere SDK for Perl
Become familiar vSphere 4.0 API Reference documentation
Step 5. Learn how to get started with writing your own Perl script using vSphere SDK for Perl
Step 6. For more scripts developed against the vSphere SDK for Perl, check out the vGhetto Script Repository for more examples!
I think the easiest way to learn this is to start playing with some of the canned scripts and to make it even easier to have an environment that's all setup for you with both the vCLI and vSphere SDK for Perl, you can download VMware vMA.