vCenter Server Appliance. Part 3 – Managing the embedded DB2 database

In this last post about the vCenter Server Appliance we will see a glimpse on how to manage the embedded database that comes bundle with the VCSA.

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.

vCenter Server Appliance. Part 2 – vCenter associated services

Welcome back to this three-part series of articles about the new vCenter Server Appliance. In this second post we will see how the additional vCenter services work in the VCSA and how to configure them.

• 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.

vCenter Server Appliance. Part 1 – Configuration and deployment

With vSphere 5 VMware has released the vCenter Server Appliance, or VCSA, a linux based alternative to the classic Windows vCenter. During the next three articles I will detail how to deploy and configure the VCSA, the vCenter additional services and how to manage the embedded database.

- 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&gt;: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.