Last week vSphere 5 Update 1 was released by VMware, along with the main products some of the SDKs and automation tools were also updated, including the vMA.
As you should remember from my first post about vMA 5 the classic vma-update utility is no longer available. So to be able to update our vMA to the new version we have to use the Web UI. Following is the procedure to perform the upgrade.
First access the web interface using the vi-admin user as always.
From the main screen go to the Update tab. In the Status screen click on Check Updates.
After a few seconds a message will appear showing the new update available.
Click on Install Updates and after asking for confirmation the update process will start.
Once the update process is complete the appliance will ask for a system reboot.
Go to the System tab and perform the reboot. After the reboot is done you can check the new version in the appliance console,
And in the vma-release file, located at /etc.
vi-admin@vma:~> cat /etc/vma-release vMA 5.0.0 BUILD-643553 Copyright (C) 1998-2011 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more U.S. Patent Numbers D617,808, D617,809, D617,810, D617,811, 6,075,938, 6,397,242, 6,496,847, 6,704,925, 6,711,672, 6,725,289, 6,735,601, 6,785,886, 6,789,156, 6,795,966, 6,880,022, 6,883,095, 6,940,980, 6,944,699, 6,961,806, 6,961,941, 6,970,562, 7,017,041, 7,055,032, 7,065,642, 7,069,413, 7,069,435, 7,082,598, 7,089,377, 7,111,086, 7,111,145, 7,117,481, 7,149,310, 7,149,843, 7,155,558, 7,222,221, 7,260,815, 7,260,820, 7,269,683, 7,275,136, 7,277,998, 7,277,999, 7,278,030, 7,281,102, 7,290,253, 7,343,599, 7,356,679, 7,386,720, 7,409,487, 7,412,492, 7,412,702, 7,424,710, 7,428,636, 7,433,951, 7,434,002, 7,447,854, 7,447,903, 7,467,067, 7,475,002, 7,478,173, 7,478,180, 7,478,218, 7,478,388, 7,484,208, 7,487,313, 7,487,314, 7,490,216, 7,500,048, 7,506,122, 7,516,453, 7,529,897, 7,543,301, 7,555,747, 7,565,527, 7,571,471, 7,577,722, 7,581,064, 7,590,715, 7,590,982, 7,594,111, 7,596,594, 7,596,697, 7,599,493, 7,603,704, 7,606,868, 7,620,523, 7,620,766, 7,620,955, 7,624,240, 7,630,493, 7,636,831, 7,657,659, 7,657,937, 7,665,088, 7,672,814, 7,680,919, 7,689,986, 7,693,996, 7,694,101, 7,702,843, 7,707,185, 7,707,285, 7,707,578, 7,716,446, 7,734,045, 7,734,911, 7,734,912, 7,735,136, 7,743,389, 7,761,917, 7,765,543, 7,774,391, 7,779,091, 7,783,779, 7,783,838, 7,793,279, 7,797,748, 7,801,703, 7,802,000, 7,802,248, 7,805,676, 7,814,495, 7,823,145, 7,831,661, 7,831,739, 7,831,761, 7,831,773, 7,840,790, 7,840,839, 7,840,993, 7,844,954, 7,849,098, 7,853,744, 7,853,960, 7,856,419, 7,856,531, 7,856,637, 7,865,663, 7,869,967, 7,886,127, 7,886,148, 7,886,346, 7,890,754, 7,895,437, 7,908,646, 7,912,951, 7,921,197, 7,925,850; patents pending. VMware, the VMware "boxes" logo and design, Virtual SMP and VMotion are registered trademarks or trademarks of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies. vi-admin@vma:~>
The above procedure use the default VMware repository and your appliance must be able to resolve public DNS addresses and access the internet in order to download de upgrade bits.
This a quick follow-up post to the How to check the driver version of a network interface in ESX(i) one. That post covered ESX(i) 4.x so I decided to write a small update for ESXi 5.0.
First I have to say that the two methods described in my first post still work in ESXi 5.0 Shell.
~ # vmware -l VMware ESXi 5.0.0 GA ~ # ~ # vmkload_mod -s e1000 | grep Version Version: Version 22.214.171.124-NAPI, Build: 456551, Interface: 9.2 Built on: Jul 29 2011 ~ # ~ # ethtool -i vmnic0 driver: e1000 version: 126.96.36.199-NAPI firmware-version: N/A bus-info: 0000:02:00.0 ~ #
Thanks to the new changes made by VMware in ESXi 5.0 we can now use esxcli to get the same result.
~ # esxcli system module get -m e1000 Module: e1000 Module File: /usr/lib/vmware/vmkmod/e1000 License: GPL Version: Version 188.8.131.52-NAPI, Build: 456551, Interface: 9.2 Built on: Jul 29 2011 Signed Status: VMware Signed Signature Issuer: VMware, Inc. Signature Digest: 1049 0611 a944 efc3 b683 341d 34b1 bebc 552d cb81 a874 ef4c 0562 8f25 2775 8c8d Signature FingerPrint: cb44 247a 1614 cea1 2079 362d ec86 9d0e Provided Namespaces: Required Namespaces: com.vmware.driverAPI@184.108.40.206, com.vmware.vmkapi@v2_0_0_0 ~ # ~ # esxcli system module get -m e1000 | grep Version Version: Version 220.127.116.11-NAPI, Build: 456551, Interface: 9.2 Built on: Jul 29 2011 ~ #
There is a big advantage on using esxcli over the other methods. In ESX(i) 4.x and ESXi 5.0 with the old procedure you had to be logged into the host but with esxcli it can be performed remotely using vSphere CLI.
vi-admin@vma:~[esxi5.vjlab.local]> esxcli system module get -m e1000 Module: e1000 Module File: /usr/lib/vmware/vmkmod/e1000 License: GPL Version: Version 18.104.22.168-NAPI, Build: 456551, Interface: 9.2 Built on: Jul 29 2011 Signed Status: VMware Signed Signature Issuer: VMware, Inc. Signature Digest: 1049 0611 a944 efc3 b683 341d 34b1 bebc 552d cb81 a874 ef4c 0562 8f25 2775 8c8d Signature FingerPrint: cb44 247a 1614 cea1 2079 362d ec86 9d0e Provided Namespaces: Required Namespaces: com.vmware.driverAPI@22.214.171.124, com.vmware.vmkapi@v2_0_0_0 vi-admin@vma:~[esxi5.vjlab.local]> vi-admin@vma:~[esxi5.vjlab.local]> esxcli system module get -m e1000 | grep Version Version: Version 126.96.36.199-NAPI, Build: 456551, Interface: 9.2 Built on: Jul 29 2011 vi-admin@vma:~[esxi5.vjlab.local]>
But there is more, thanks to Get-EsxCli cmdleet the same operation can be done using PowerCLI, here it is how.
First we need to setup the Esxcli instance.
And now we issue the command using the name of the module as the argument, please pay attention to the syntax.
As you should have imagined this procedure can be used to get info about any VMkernel module in the host, not just the network interface one,.
We are going to suppose that you are trying to troubleshoot your ESXi network problems and as an experienced sysadmin one of the first things to do is getting the network connections of the host. But you are in ESXi and that means there is no netstat command, that handy Unix command that saved your life so many times in the past.
Please don’t panic yet, because as always in VMware there is a solution for that: esxcli to the rescue. Here it is the way to list the network connections of your ESXi host, both for ESXi 4.1 and ESXi 5 :-)
I tested it in ESXi 4.1 and ESXi 4.1 Update 1. The network namespace is not available in ESXi 4.0.
I used Remote Tech Support (SSH), simply known as SSH in ESXi5, in both examples but you can also launch the command from the vMA or using vSphere CLI from a Windows or a Linux machine.
[vi-admin@vma ~]$ esxcli --server=arrakis.jreypo.local --username=root network connection list
vi-admin@vma5:~> esxcli --server=esxi5.jreypo.local --username=root network ip connection list
One of features I like the most of esxtop/resxtop is the ability to create customized configurations. This feature gives you the ability to have several pre-defined configuration files to be used under certain circumstances, for example you can have one only to check if there are virtual machines swapping during a heavy workload period.
The post will cover esxtop 4.x, the version that comes with vSphere 4.x, however it can be applicable to previous versions as well. First it’s important to know that by default esxtop/resxtop stores its configuration in the file .esxtop4rc, in the vMA this file is stored in the vi-admin user home directory and in the root home directory in the ESX(i) servers.
Now lets create one as an example. I’m using resxtop from the vMA so first launch it against the vCenter Server and select one of the ESX(i) hosts.
Show the memory screen by pressing m and from there press f to edit the fields to display.
Press the corresponding keys to enable/disable the fields and a or o keys to toggle its order, then press the space bar to finish. Next esxtop returns the memory view and show the newly selected counters.
At this point you can customized the field to display in the other views (CPU, network, etc). When you are done press W to save the config and enter the file name to save the new config in. If you don’t enter a file name esxtop will save the changes in its default config file, /home/vi-admin/.esxtop4rc in the example.
Exit esxtop and run it again but loading the saved config file, instead of the default one, by using -c <config_file>.
Finally my advise is to read carefully the Interpreting esxtop 4.1 Statistics document and use the counters that better suits your needs.
When you are trying to configure iSCSI of and ESX(i) server from the command line is clear that at some point you are going to need the iqn. Of course you can use the vSphere Client to get the iqn but the Unix Geek inside me really wants to do it from the shell.
First list the SCSI devices available in the system to get the iSCSI hba.
[root@esx02 ~]# esxcfg-scsidevs -a vmhba0 mptspi link-n/a pscsi.vmhba0 (0:0:16.0) LSI Logic / Symbios Logic LSI Logic Parallel SCSI Controller vmhba1 ata_piix link-n/a ide.vmhba1 (0:0:7.1) Intel Corporation Virtual Machine Chipset vmhba32 ata_piix link-n/a ide.vmhba32 (0:0:7.1) Intel Corporation Virtual Machine Chipset vmhba33 iscsi_vmk online iscsi.vmhba33 iSCSI Software Adapter [root@esx02 ~]#
After that Jon uses the command vmkiscsi-tool to get the iqn.
[root@esx02 ~]# vmkiscsi-tool -I -l vmhba33 iSCSI Node Name: iqn.1998-01.com.vmware:esx02-42b0f47e [root@esx02 ~]#
Beauty, isn’t it? But I found one glitch. This method is done from the ESX root shell but how do I get the iqn from the vMA? Some of my hosts are ESXi and even for the ESX I use the vMA to perform my everyday administration tasks.
There is no vmkiscsi-tool command in the vMA, instead we are going to use the vicfg-iscsi or the vicfg-scsidevs command.
With vicfg-scsidevs we can obtain the iqn listed in the UID colum.
[vi-admin@vma ~][esx02.mlab.local]$ vicfg-scsidevs -a Adapter_ID Driver UID PCI Vendor & Model vmhba0 mptspi pscsi.vmhba0 (0:16.0) LSI Logic Parallel SCSI Controller vmhba1 ata_piix unknown.vmhba1 (0:7.1) Virtual Machine Chipset vmhba32 ata_piix ide.vmhba32 (0:7.1) Virtual Machine Chipset vmhba33 iscsi_vmk iqn.1998-01.com.vmware:esx02-42b0f47e () iSCSI Software Adapter [vi-admin@vma ~][esx02.mlab.local]$
And with vicfg-iscsi we can get the iqn providing the vmhba device.
[vi-admin@vma ~][esx02.mlab.local]$ vicfg-iscsi --iscsiname --list vmhba33 iSCSI Node Name : iqn.1998-01.com.vmware:esx02-42b0f47e iSCSI Node Alias : [vi-admin@vma ~][esx02.mlab.local]$
The next logical step is to use PowerCLI to retrive the iqn, but I’ll leave that for a future post.
As a small follow-up to yesterday’s post about NFS shares with Openfiler in the following article I will show how to add a new datastore to an ESX server using the vMA and PowerCLI.
From the vMA shell we are going to use the command vicfg-nas. To clarify things a bit for teh newcomers, vicfg-nas and esxcfg-nas are the same command, in fact esxcfg-nas is no more than a link to the first.
The option to create a new datastore is -a and additionally the address/hostname of teh NFS servers, the share and a label for teh new datastore must be provided.
[vi-admin@vma ~][esx01.mlab.local]$ vicfg-nas -l No NAS datastore found [vi-admin@vma ~][esx01.mlab.local]$ vicfg-nas -a -o openfiler.mlab.local -s /mnt/vg_nfs/lv_nfs01/nfs_datastore1 nfs_datastore1 Connecting to NAS volume: nfs_datastore1 nfs_datastore1 created and connected. [vi-admin@vma ~][esx01.mlab.local]$
When the operation is done you can check the new datastore with vicfg-nas -l.
[vi-admin@vma ~][esx01.mlab.local]$ vicfg-nas -l nfs_datastore1 is /mnt/vg_nfs/lv_nfs01/nfs_datastore1 from openfiler.mlab.local mounted [vi-admin@vma ~][esx01.mlab.local]$
In the second part of the post we are going to use vSphere PowerCLI, which as you already know is a PowerShell snapin to manage vSphere/VI3 infrastructure. I will write more about PowerCLI in the since I’m very fond with it.
The cmdlet to create the new NFS datastore is New-Datastore and you must provide the ESX host, the NFS server, the path of the share and a name for the datastore. Then you can check that the new datastore has been properly added with Get-Datastore.
This post is mostly for self-reference but may be someone would find it useful. Last night I decided to change the IP address of one of the Openfiler instances in my homelab and instead of previously removing the NFS shares from the ESX servers I simply made the changes.
After a restart of the network services in the Openfiler server to commit the changes I found that the ESX servers saw the datastore as inactive.
First I tried to remove it from the vSphere Client and I received the following error message:
I quickly switched to an SSH session in the vMA to check the state of the datastore, it appeared as not mounted.
[vi-admin@vma /][esx01.mlab.local]$ esxcfg-nas -l nfs_datastore1 is /mnt/vg_nfs/lv_nfs01/nfs_datastore1 from openfiler.mlab.local not mounted [vi-admin@vma /][esx01.mlab.local]$
At this point I used esxcfg-nas command to remove the datastore.
[vi-admin@vma /][esx01.mlab.local]$ esxcfg-nas -d nfs_datastore1 NAS volume nfs_datastore1 deleted. [vi-admin@vma /][esx01.mlab.local]$ esxcfg-nas -l No NAS datastore found [vi-admin@vma /][esx01.mlab.local]$
Very easy, isn’t it? Oh by the way this just confirm one of my personal beliefs “Where there is shell, there is a way” ;-)