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.

Change ESXi 5.0 hostname with esxcli

Yes another post about esxcli, what can I say I’m studying very hard for my VCP5 and from time to time this kind of unknown information, at least for me, arise and I believe it can be useful for some of you.

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.

Getting network card driver version in ESXi 5.0

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

Change ESXi 5.0 Shell keyboard layout with esxcli

If you have to login into the ESXi 5.0 Shell and the keyboard layout is not the one you are used to this post will show how to quickly change it.

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.

Monitor ESX 4.x to ESXi 5.0 migration process

During the migration of an ESX 4.x to ESXi 5.0 the whole process can be monitored directly from the console of the server.

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.