This year yours truly is lucky enough to be on the list of candidates so if you feel that my work here have been of help I’ll be grateful. However I’m a guy with his feet on the ground and I am perfectly aware that there are a ton of great blogs out there.

My personal Top Five are:

• Virtually Ghetto by William Lam (@lamw)
• DoubleCloud by Steve Jin (@sjin2008)
• Nickapedia by Nick Weaver (@lynxbat)
• Scott Lowe’s blog (@scott_lowe)
• Frank Denneman’s blog (@FrankDenneman)

Now go to http://vote.vsphere-land.com/ and vote for your favorite blog!

Juanma.

This images comes bundled with utilities and drivers not included in the standard VMware image that allows ESXi to run flawlessly on HP hardware.

You can retrieve the packages specifically provided by using the esxcli command.

~ # esxcli software vib list |grep Hewlett-Packard
char-hpcru            5.0.0.8-1OEM.500.0.0.434156         Hewlett-Packard     PartnerSupported  2011-04-16 
char-hpilo            500.9.0.0.8-1OEM.500.0.0.434156     Hewlett-Packard     PartnerSupported  2011-04-16 
hp-esx-license        1.0-03                              Hewlett-Packard     PartnerSupported  2011-04-16 
hp-smx-provider       500.02.10.13.44-434156              Hewlett-Packard     VMwareAccepted    2011-04-16 
hpbootcfg             01-00.10                            Hewlett-Packard     PartnerSupported  2011-04-16 
hponcfg               03-02.04                            Hewlett-Packard     PartnerSupported  2011-04-16 
~ #

To get detailed information of any of those packages use the following command.

~ # esxcli software vib get -n hp-smx-provider
Hewlett-Packard_bootbank_hp-smx-provider_500.02.10.13.44-434156
   Name: hp-smx-provider
   Version: 500.02.10.13.44-434156
   Type: bootbank
   Vendor: Hewlett-Packard
   Acceptance Level: VMwareAccepted
   Summary: HP Insight Management WBEM Providers for ESXi
   Description: HP Insight Management WBEM Providers for ESXi
   Release Date: 2011-07-15
   Depends:
   Conflicts:
   Replaces:
   Provides: cim.DMTF.DSP1004 = 1.0.0, cim.SNIA.FC-HBA = 1.3.0
   Maintenance Mode Required: False
   Hardware Platforms Required: HP, hp, Hewlett-Packard, Hewlett-Packard Company
   Live Install Allowed: True
   Live Remove Allowed: False
   Stateless Ready: True
   Overlay: False
   Tags:
   Payloads: hp-smx-provider
~ #

Aside from the drivers and monitorization agents, the HP image also adds two additional namespaces to esxcli.

• hp
• hpbootcfg

The first one, hp, manage the HP NMI driver.

~ # esxcli hp
Usage: esxcli hp {cmd} [cmd options]
Available Namespaces:
  hpnmi                 The default set of operations for the hpnmi command
~ # esxcli hp hpnmi
Usage: esxcli hp hpnmi {cmd} [cmd options]
Available Commands:
  load                  Verifies HP server and Loads hpnmi module on supported servers
~ #

The hpbootcfg namespace is used to configure the device boot order of the server. This can be permanent or a one time boot change.

~ # esxcli hpbootcfg
Usage: esxcli hpbootcfg {cmd} [cmd options]
Available Commands:
 execute execute hpbootcfg command with options parameter
 help show hpbootcfg help
 show show current hpbootcfg settings
~ #
~ # esxcli hpbootcfg show
00 00: Normal Device first, normal boot process

~ #
~ # esxcli hpbootcfg execute --help
Usage: esxcli hpbootcfg execute [cmd options]
Description:
 execute execute hpbootcfg command with options parameter
Cmd options:
 -b|--bypass bypass F1/F2
 -C|--cdrom CD ROM first
 -D|--defaults Set Defaults everywhere
 -d|--dialout one time remote dial out
 -F|--floppy Floppy first
 -H|--harddrive Harddrive first
 -n|--network one time remote network
 -P|--pxe one time boot to PXE
 -Q|--qcu one time boot to quick configuration utility
 -R|--rbsu one time boot to RBSU
 -r|--remote one time remote
 -S|--scu one time boot to system configuration utility
 -T|--tape Tape first
~ #

Juanma.

Professionally the great company I’m lucky to work at finally gave me the opportunity to focus my work only in the most awesome technology… VMware. After many years of being a Unix guy and a few being something in the middle I’m currently working exclusively with VMware products on top of HP solutions.

From the blog perspective 2011 has been huge, and I really mean it. In 2010 I had 29,786 visits and in 2011 I have had… 125,690. Yes almost one hundred thousand more visits!

Thanks to good work of John Troyer the blog has been recently included in the Planetv12n blog aggregator from VMware.

And probably the best moment of the year… in June I got news from John Troyer telling me that I had been awarded vExpert for the first time. It was a great honor and I’m still a bit shocked.

Personally the vExpert award was huge, apart from HP-UX and OpenBSD I never be so passionate about a technology and it was an unexpected a very welcomed gift. Props to VMware and to John Troyer, there is no place like the VMware Community :-)

Finally I want to say:

THANK YOU!

Thank you to all my readers and my Twitter followers. My best wishes to you and your families for the New Year. And again… Thank you!

Juanma.

First I must say that I AM NOT A DB2 ADMIN. I got this info by playing with the VCSA in my homelab, digging a bit into the DB2 documentation and googling a lot. Use the information provided in this post at your own risk.

If you still want to risk the integrity of your precious appliance please keep reading :-)

“Disassembling” the database installation

Before starting to launch commands against the database we need to know a bit about it. Since this is SuSE Linux check the rpm packages installed.

Now that we now it is DB2 Express version 9.7.2-1, list the files in the package.

This is very interesting, the package doesn’t contain the database but the installation files. The reason for this is very simple, by default DB2 is not installed in the appliance. The Web UI gives you the option to use an Oracle external database or an embedded one.

When you select embedded and click Save Settings is when VCSA starts the installation and configuration of the database. Change to /opt/db2/db2expc_9.7.2_install and look at the contents.

There are four are files, the same showed by the rpm command.

• db2exc_972_LNX_x86_64.tar.gz – The DB2 database itself.
• do_db2_install – The installation script.
• db2_create_script.sql – SQL script used by the installation script to create the vCenter database and the schema.
• db2expc.rsp – An answer file used during the installation.

Feel free to take a more detailed look at the files.

Now move to the parent directory, /opt/db2, here you will find the installation directory and two links named current and home. The first will always point to the latest installed version and the second to the home directory for the db2 user. We’ll see more about this user later.

Change to current and the database directory structure will show up. There is a logs symlink, this link point the installation log directory.

The log file is called db2install.history again my advice is to review this log file, along with the installation files it can be a real learning experience about the DB2 installation process.

Identifying the database

OK we know how the database was installed now we need to know how it works. Check for the DB2 processes.

Apart from root there are three other users:

• db2inst1
• db2fenc1
• dasusr1

Look for these users in /etc/passwd.

The user db2inst1 is the only one who has a login shell, this is the database admin user.

The home directory for the three users is the same that symlink home pointed at in /opt/db2. This is where the DB2 environment is loaded from.

Make yourself db2inst1 to load the DB2 environment. For the majority of the operations we will use the db2 command. Db2 is the IBM DB2 Command Line Processor, it runs SQL statements against the database and it can be used in interactive mode, command mode and batch processing mode.

First thing is to know which DB2 version is installed. Use the db2ls command.

As you can see the VCSA is running IBM DB2 9.7.0 FixPack 2. The Install Path is also displayed.

Next is checking DB2 database manager. Use the db2start command to check if the manager is running.

Try to stop the manager with db2stop.

Since the vCenter database is active the operation is not allowed, to force the stop use db2stop force.

Then start again the database manager.

We are going now to get the running instances. There are two commands to perform this operation. db2ilist and db2 get instance.

As you probably know many databases can be created within the same instance so we are going to list the databases created.

As expected only one database is created and its name is VCDB… Surprise!

In a DB2 installation we can also list the active databases, of course in the VCSA only one will be active.

Open a connection to the database and retrieve connection state.

Once the connection is established we can get detailed information about the database, using again the db2 command line processor.

List the tablespaces of the database.

There are many more options available within db2 utility, I’ll let up to you to investigate them further.

Querying the DB2 database

The final part of our trip is to interrogate the DB2 database. We will use the isql utility, that comes bundles with the VCSA, to perform a few basic SQL queries. This tool is part of the unixODBC project, you can find more about it in their website.

And again we will use the db2 command line processor.

- isql

You don’t need db2inst1 user to use isql, being root will suffice. To connect to the vCenter database first we need the vc user credentials. This is not a system user but a database one.

To get vc user password list the contents of /etc/vmware-vpx/embedded_db.cfg.

The EMB_DB_PASSWORD variable contains the password.

Open a connection to the database passing the database ID, user and password as arguments.

Now we will interrogate the database tables. Please take into account that in my installation these tables are empty since this a lab environment, in a production one they will be populated.

If you want to know which tables are created have a look at the SQL file VCDB_db2.sql. This file is in the vCenter Server media, the Windows one, in the vCenter-Server\dbschema folder. This file is used by the Windows-based vCenter to create the database schema during the installation process when it is connected to an IBM DB2 database.

Following are a couple of SQL commands you can use. Feel free to investigate the above file, I found it very helpful to understand how he vCenter database is constructed.

Get contents of vpx_product and vpx_version tables.

Get the virtual datacenter ID, contained in the vpx_datacenter table.

- db2 command line processor

Make yourself db2inst1 user and launch the db2 shell.

Connect to the database using the same connect to VCDB statement we saw in the previous section.

Now we can run our SQL queries. In db2 there is no need to end the command with ‘;’ as we did in isql.

For the tables you need to prefix the tables with vc, the owner of the tables.

Or set the schema at the beginning.

And with this we are done with the vCenter Server Appliance series. Hope it will be of help for any of you my dear readers. Please feel free to comment with questions, corrections or any additional tip.

Juanma.

• Syslog Collector
• ESXi Dump Collector (AKA Netdumper)
• Auto Deploy

Additionally and although is not a service I decided to include a section about how to collect the vm-support scripts in the VCSA.

Syslog Collector

Unlike the vCenter Windows version Syslog Collector comes bundled with the VCSA. As we saw in the previous post it can be configured from the VCSA web interface.

But there are also a limited range of operations that can be done from the command line. Access the VCSA via SSH and make yourself root.

Look if the Syslog Collector is enabled.

Check its status.

Start and stop the Syslog Collector service.

This last option is quite useful since the web interface only allows to stop/start ALL the ESXi Services at once and not individually.

If you want to take a look at the Syslog Collector configuration, the configuration file is located at /etc/syslog-ng/syslog-collector.conf.

ESXi Dump Collector

Like the other services ESXi Dump Collector, also known as netdumper, comes installed with the VCSA and like the Syslog Collector is enabled by default.

It can be configured from the appliance Web UI in the Services tab.

From a root shell you can check the status of the service.

And start/stop the service.

The configuration of the Dump Collector is located at /etc/sysconfig/netdumper.

Take a look at the following variables:

• NETDUMPER_DIR – Storage point for the cores.
• NETDUMPER_DIR_MAX – Amount of space configured for the cores.
• NETDUMPER_PORT – TCP port of the service, set from the web UI.
• NETDUMPER_LOG_FILE – Netdumper log file location
• NETDUMPER_OPTIONS

From this file you can manually customize all those values, however for the port I prefer to use the web interface.

Auto Deploy

Auto Deploy is the only one of the three services that is not enabled by default. As in the Windows based vCenter version Auto Deploy relies on two services:

• DHCP
• TFTP

In the vCenter Server Appliance those services are included in the SuSE Linux the appliance is based on. However by default thoser services are stopped and are configured to do not start during the system startup process.

These services require of some configuration before they can be used.

DHCP:

The configuration file for DHCP is /etc/dhcpd.conf but instead of using the default configuration file make a backup of this file and substitute the original with a copy of /etc/dhcpd.conf.template.

Once that is done edit the file, it should look like this.

Substitute the values between @@ with the values for your network. You may have to comment some of the lines. My dhcpd.conf file is below as reference:

Next you have to modify the /etc/sysconfig/dhcpd file. In this file is where the interfaces to listen at for the DHCP server are configured.

Check the DCHP_INTERFACE variable.

If it is empty edit the file and set the value to eth0.

With the configuration done we need to start the service.

And configure the service startup level.

TFTP:

The configuration file for TFTP server is /etc/sysconfig/atftp. There is no need to modify this file since it will work with the default values.

To use a different directory for TFTP server modify the ATFTPD_DIRECTORY variable. If you list the contents of that directory you can see the PXE boot files used during the boot of the ESXi server by the Auto Deploy service.

Start the atftpd daemon.

And set the startup level for the service.

With the DHCP and TFTP service properly configured and running we can now go back to the VCSA web administration interface and start Auto Deploy. To perform the startup of the service simply click in the Start ESXi Services button.

Collecting vm-support scripts

We all know how to generate a support bundle in previous vCenter Server versions and in the 5.0 Windows based one using the vSphere Client or from the Windows OS.

For the VCSA the vSphere Client method is completely valid but of course since it is running on SuSE Linux the Windows method doesn’t apply. Instead VMware has provided us with two additional methods, one from the Web administration interface and one from the Linux shell.

- Linux shell method

As root got to /usr/lib/vmware-vpx and run the vm-support.sh script. By default this script will generate the bundle in the current directory but you specify an alternate location with the -w flag.

When the operation is done the following message will appear.

Go to the directory where the file has been generated to check it. You can have a quick look of the contents of the bundle using unzip -l.

You can download the bundle to your system using you favorite SCP client.

- Web UI method

Go the vCenter Server tab and in the Status section there is a link to generate the bundle.

Click on the link, a new tab/windows will show up where the log of the operation is displayed. The page refresh every ten seconds until the operation is done.

Then a link to download the bundle will appear. If you look carefully at the log you will see that this method is no more than a more user friendly version of the Linux shell one.

This file is located at /tmp/vc-support-bundle/<randomly_generated_directory>.

We are done with the vCenter services post. In the next posts I’ll show you how to manage the embedded DB2 database.

Juanma.

- VCSA feature and limitations

The VCSA is a SuSE Linux Enterprise Server 11 64-bit virtual machine with the vCenter Server software and its associated services pre-installed. These services include:

• ESXi Dump Collector
• ESXi Syslog Collector
• vSphere Auto Deploy

I will explain how these services are configured in the VCSA in the next article.

The appliance has a minimum requirements of 4GB of RAM, 7GB of disk space and 2 vCPUs. For a more detailed descriptions of the VCVA requirements you should check this VMware Knowledge Base article:

• Minimum requirements for the VMware vCenter Server 5.x Appliance

The are some limitations for the VCSA, the following vCenter Server features are not supported:

• IPv6
• Linked mode
• SQL Server as backend database
• Security Support Provider Interface (SSPI)
• VMware Update Manager can’t be installed in the VCSA, you have to use an additional Windows based VM or physical server.

- VCSA configuration

The vCenter appliance can be deployed only on hosts ESX(i) 4.x or later and like the appliance produced by VMware it comes in OVF format.

Deploy your VCSA from the vSphere client. I will not describe this process since it is very well known and has been very well described in many blog articles and in VMware documentation.

Once the VCSA is deployed check it within you vSphere Client. As you will see the appliance is configured with 2 vCPUs and 8GB of RAM by default.

^

Power on the vCenter Server Appliance and open its console.

From the console we can configure the VCSA networking and timezone and we can log into the SLES console.

Select Configure Network, a new screen will show and the appliance will ask for its IP address, hostname, gateway and DNS configuration. Answer the questions according to your network environment.

After this enter the time zone configuration.

And select from the list your time zone.

With the network and time zone properly configured proceed to your browser and point the URL showed in the console main screen, https://<VCSA_IP_ADDRESS>:5480.

The default username and password for the appliance are root/vmware.

You will now be presented with a tabbed interface. After accepting the EULA move to the Database area within the same tab.

In this screen you have to select the database type. The VCSA can only be configured to use the embedded DB2 database or an Oracle external one.

For my homelab VSA I decided to use the embedded DB2.

If you are going to use the external Oracle option the credentials and network information for the database server have to be provided. Once you are done click Save Settings. For the external option you can test your configuration and a database reset option is also provided in case you need it.

In the same screen move to the Settings section. Here you can specify the inventory size and the vCenter ports. Click Save Settings when you are and like with the database configuration you can perform a test.

In Administration you can change the administrator account password and enable or disable SSH access to the appliance.

Last for the vCenter Server tab is the Storage screen where you can configure a NFS share to store the log and core files. keep in mind that for this changes to take effect you will need to restart the VCSA.

The next tab is Services. From this tab you can configure, start/stop the ESXi Services (Syslog, Netdumper, Auto Deploy) and start/stop the vSphere Web Client.

In the Status section you can start and stop the services and in the other sections the ports for each one of the ESXi Services can be defined, below is the Syslog screen as an example.

Move to the Authentication tab. The vCenter Server Appliance can be configured to use a NIS or Active Directory. Again if you set any of them you’ll need to restart the VCSA for the changes to take effect.

In the Network tab you will be able to set the network configuration for the appliance and a proxy server if you want the appliance to be able to access Internet in order to get its updates.

The System tab is quite simple, here you can reboot or shutdown the appliance and the Time Zone.

Next is the Update tab. From the Status section you can get information about the VCSA and check for updates.

In the Settings tab you can configure how the updates are performed and set an update repository different from the VMware default one.

Finally there is the Upgrade tab. You are not going use this tab until the next release of vSphere 5.

The VCSA can not be upgraded in the same manner as its Windows counterpart. Instead you’ll have to deploy the new version within your infrastructure and use this interface to establish a trusted connection between the new and old VCSAs. The new appliance will import all data, shutdown the old one and finally take control of its inventory.

We are done with the configuration of the appliance. In the second post of the series I will discuss about the vCenter associated services.

Juanma.

Again we are going to make use of the system namespace.

~ # esxcli system hostname
Usage: esxcli system hostname {cmd} [cmd options]
Available Commands:
  get                   Get the host, domain or fully qualified name of the ESX host.
  set                   This command allows the user to set the hostname, domain name or fully qualified domain name of the ESX host.
~ #

First task of course is to get current hostname.

~ # esxcli system hostname get
   Domain Name: vjlab.local
   Fully Qualified Domain Name: esxi5.vjlab.local
   Host Name: esxi5
~ #

Next change the hostname, but you should check before what options are at your disposal by getting the command help.

~ # esxcli system hostname set --help
Usage: esxcli system hostname set [cmd options]
Description:
  set                   This command allows the user to set the hostname, domain name or fully qualified domain name of the ESX host.
Cmd options:
  -d|--domain=<str>     The domain name to set for the ESX host. This option is mutually exclusive with the --fqdn option.
  -f|--fqdn=<str>       Set the fully qualified domain name of the ESX host.
  -H|--host=<str>       The host name to set for the ESX host. This name should not contain the DNS domain name of the host and can only contain letters, numbers and '-'. NOTE this is not
                        the fully qualified name, that can be set with the --fqdn option. This option is mutually exclusive with the --fqdn option.
~ #

Interesting, you can change the short hostname, the domain or the fully qualified domain name. Take into account that –fqdn option is mutually exclusive with the others.

We are going to try all of them.

Domain:

~ # esxcli system hostname set --domain=jreypo.local
~ #
~ # esxcli system hostname get
   Domain Name: jreypo.local
   Fully Qualified Domain Name: esxi5.jreypo.local
   Host Name: esxi5
~ #

Short hostname:

~ # esxcli system hostname set --host=esxi5-2
~ #
~ # esxcli system hostname get
   Domain Name: jreypo.local
   Fully Qualified Domain Name: esxi5-2.jreypo.local
   Host Name: esxi5-2
~ #

Fully qualified domain name:

~ # esxcli system hostname set --fqdn=esxi5.vjlab.local
~ #
~ # esxcli system hostname get
   Domain Name: vjlab.local
   Fully Qualified Domain Name: esxi5.vjlab.local
   Host Name: esxi5
~ #

Juanma.

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 8.0.3.1-NAPI, Build: 456551, Interface: 9.2 Built on: Jul 29 2011
~ #
~ # ethtool -i vmnic0
driver: e1000
version: 8.0.3.1-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 8.0.3.1-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@9.2.0.0, com.vmware.vmkapi@v2_0_0_0
~ #
~ # esxcli system module get -m e1000 | grep Version
   Version: Version 8.0.3.1-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 8.0.3.1-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@9.2.0.0, 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 8.0.3.1-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,.

Juanma.

As always in vSphere 5 we are going to use esxcli command to get the job done.

Get current keyboard layout:

As you can see we are using system settings keyboard layout namespaces and the command get. The other available commands are list and set.

List available layouts:

Change keyboard layout:

The syntax for the command can be retrieved by appending –help to the command.

Now change the layout to “US Default”.

Keep in mind that this will change the layout permanently, as it can be seen in the command help the layout can also be changed only for the current boot and it will be reset to its original value during next reboot of the host.

With the —no-persist option the host will report its original layout.

Juanma.

Once the process has started press Alt-F1 to access the Console. Login with root and blank password.

From here you can go to the /var/log folder and using the tail command monitor the ESXi log files.

Also by pressing Alt-F12 you will see the vmkernel log, this log will show the upgrade process in real time. Once the log reaches the point in the screenshot the upgrade will be complete.

At this point and before restarting the host if you go back again to the ESXi console you can review the ESXi install log file, called esxi_install.log which in fact is a symlink to the file weasel.log.

In this log file you can observe the whole migration process, I strongly recommend to lose a few minutes on this since you will learn a lot of under the hood info about the ESXi installation process.

Finally and only as a curiosity after the reboot if you login into the ESXi Shell a message indicating that the system has been migrated to ESXi 5.0 will be displayed before the prompt.

Juanma.