Today VMware has released the latest release of vCenter Chargeback Manager. Although this release is more an update than a completely new one that doesn’t mean it comes without new features, on the contrary. The full list of new features and more information about 2.6 release of Chargeback can be found on its Release Notes. Some of the most interesting are:
- Compatibility with 5.5 versions of vSphere and vCloud Director
- Windows Server 2012 Standard support as host operating system
- Microsoft SQL Server 2012 s supported database
However amongst every other new feature the one that has immediately captured my attention is that finally the vCenter Server Appliance vPostgres embedded database is supported. For me it is a very welcomed new addition, combining CBM 2.6 with vCSA 5.5 you can now manage the cost of your vSphere environment without the need of having an external Oracle database or a Windows-based vCenter Server.
In the Add a New vCenter Server dialog you will notice that Postgres now appears as an option.
For this option there no need to configure database user, instance or port; just provide vCSA IP/FQDN, root user password and we are done.
When the process is completed the newly configured vCenter Server and its database can be checked as always in the settings tab.
In the last post we discussed about the new features and changes that comes with version 5.1 of the VMware vCenter Server Appliance. In this new one I will explain how to deploy it and perform an upgrade.
The deployment of the VCSA 5.1 is very similar to the previous version. Use the vSphere Client to deploy a new OVF template and browse to the VCSA OVA package, follow the instructions until you get to the Networking Properties screen.
Here you can pre-set the networking configuration values of the appliance.
If you are going to do a fresh VCSA or vSphere installation enter the appropriate values on each field. If you want to perform an upgrade instead leave them blank to get the info by DHCP or put a temporal IP address if there is no DCHP server in place. You don’t need to put here the final values since during the upgrading process all the network settings will be migrated.
Let the deployment process finish and power on the vCenter appliance. During the boot process you can see how the network configuration is applied to the VM.
And finally you will reach the familiar blue screen.
That’s it, now proceed to the WebUI to complete VCSA setup. In your first log into the vCenter a wizard will appear.
After accepting the EULA you will presented with four options:
- Configure with default settings
- Upgrade from a previous version, which also gives you the option to use the default Single Sign On configuration.
- Upload configuration file. Very useful in case your vCenter Server virtual machine gets corrupted or you messed it up, if have a saved copy of the most recent configuration file you can deploy a new appliance and quickly restore its settings by uploading it.
- Set custom configuration <- I used this option for my homelab testing.
In the next screen you choose which database you want to use, the vPostgres embedded or an Oracle external.
Now we must choose the options for the Single Sign On server. vCenter 5.1 comes with a new component known as the Single Sign On server, or SSO.
SSO allows an administrator to login through the vSphere Web Client or the API and perform operations across all components of the vCloud Suite without having to log into them separately. It integrates with multiple identity sources like Windows Active Directory, NIS and OpenLDAP. The SSO is a requirement for the Inventory Service, vCenter Server and the Web Client.
In the Windows based vCenter installer SSO comes as a separate component that can be installed in the same VM as the vCenter or in a different one as a stand-alone server, in High Availability mode or even in a multisite environment.
The VCSA comes with the SSO embedded however it is prepared to use an external SSO server too. If choose the external SSO deployment mode all the appropriate information must be provided in this screen. Again as with the vCenter itself the database type must be set.
Finally set the Active Directory configuration accordingly to your environment, review the configuration and click Start to begin.
At the end if everything goes fine you will see a screen with a confirmation, click close and will see al the vCenter services up and ready in the main screen of the WebUI.
The deployment and basic setup of the VCSA is done, at this point all other components and settings can be setup from here.
The upgrade of the vCenter Server Appliance will allow to update to a different OS version and migrate to a different database.
If you are upgrading from 5.0 to 5.1 and using the embedded database, it will be migrated from IBM DB2 to VMware vPostgres. The configuration state will be preserved and the schema will be upgraded in order to be compatible with 5.1. VCSA 5.0 Update 1 already comes with vPostgres instead of DB2.
The major upgrade is supported from 5.0 and updates to 5.1.
The upgrading process is relatively simple:
- Deploy VCSA 5.1.
- Set the 5.0 appliance as source and 5.1 as destination.
- Establish a connection between both VCSAs.
- Import network configuration of existing VCSA.
- Prior to the upgrading the VCVA 5.1 must have a valid network connection and vCenter Server service must be stopped and un-configured.
Deploy the appliance as shown above, log into the WebUI and in the wizard accept the EULA in the first screen and select Upgrade from previous version in the second, let Use default SSO configuration as it comes by default.
The next screen that will be displayed is the Local and Remote Appliance keys.
Here we have put the current VCSA 5.0 key. To do so go to the Upgrade tab in VCSA 5.0 web interface. In the Prepare section select source and click Set role.
Go back to the VCSA 5.1 and copy the Local appliance key. On the 5.0 appliance click on Establish Trust and paste the copied key in the Remote key appliance key field. Click on Import remote key and wait for the import to complete.
In the VCSA 5.0 copy the Local appliance key. Go to 5.1 vCenter, paste that key on the Remote appliance key field of the setup wizard screen and click Next. The Pre-Upgrade Checker screen will show up.
After this a check will be run against the ESX/ESXi managed by the old VCSA and it will generate a report.
And the final screen will appear asking for confirmation. Click on the confirmation checkbox and in Start.
During the upgrade VCSA 5.1 will shutdown the 5.0 virtual appliance and assumes its network identity.
When the process is done a final screen will appear.
If you want to check if the process is done log into the VCSA through SSH and list the vmware services, vmware-sso just to name one will show up on the list.
Also you can access the vSphere Web Client and will see the new 5.1 client.
Yesterday was a very exciting day, VMware finally announced the new vCloud Suite 5.1. With new products and features announced, each one of them as great as ever.
But yours truly decided that instead of presenting you a generic “What’s new” post it was more interesting, at least for me and hope also to you, to focus in one of my favorite pieces of vSphere, the vCenter Server Virtual Appliance and in a couple of articles describe what new features are coming and how to perform an upgrade from 5.0 to 5.1.
What’s new in the VCSA 5.1
With this new release of the vCenter Server VA a few new features have been added, most of them related to the WebUI and to the new features and services that have been released globally for the vCenter 5.1, Windows and Linux based versions.
These new enhancements can be seen in the Summary section of the vCenter Server Tab as shown in the screenshot below.
From here all the vCenter Service can be started and stopped. The Services Tab no longer exists and it’s now a section of the vCenter Server Tab.
In the Storage Usage are you can check the disk usage of the different components of the VCSA.
There is also a Utilities are where you can:
- Generate a support bundle in case of an incidence with the vCenter Server.
- Download the configuration file of the VCSA and then open it in your favorite text editor.
- Launch again the Setup Wizard to configure the VCSA from scratch or make modifications to some of he initial settings.
- Upload the Windows Sysprep files to the vCenter VA.
- For this last option the procedure is quite simple. Click the
A new windows will open, select the operating system and browse for the location of the files.
The files will be uploaded to /etc/vmware-vpx/sysprep/<OS>.
Additionally in the vCenter Server Tab two new sections have been added.
The Service section where the VCSA administrator can setup:
- ESXi Dump Collector repository size
- vSphere Auto Deploy repository size
- Inventory size
The SSO section. Here you can configure all the settings related to the newly introduced Single Sign On server.
In the next post we will discuss about VCSA 5.1 initial deployment and how to upgrade from 5.0 and 5.1.
If your vCSA is configured to use the embedded DB2 database and if it’s not properly shutdown, next you power it on may be you should not be able to power on a VM like in the screenshot below…
…or the vSphere Client will not show some of information about the host or the VMs.
We all have seen those kind of errors in our homelabs from time to time. In the Windows-based vCenter it was relatively easy to solve, close the client, log into the vCenter, restart the vCenter Server service and in the next login into the vSphere Client everything will go as expected.
However how can we resolve this issue in the vCenter Linux appliance? Can’t be easier.
There are two ways to restart the vCenter services in the vCSA:
- From he WebUI administration interface
- From the command line
For the first method log into the WebUI of the vCSA by accessing https://<vCSA_URL>:5480 with your favorite web browser.
In the vCenter Server screen in the Status tab there stop and start the vCenter Server service from the Action buttons.
The second method is faster and easier, and to be sincere it feels more natural for me and probably for the other Unix Geek/Sysadmins out there.
The vCenter service in the Linux appliance is vmware-vpxd so with a simple service vmware-vpxd restart we’ll be on business again. Check the screenshot below.
Finally as seen in the screen capture you can check the status of the service.
More on troubleshooting the vCSA in a future post.
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:
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.
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.
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.
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
From this file you can manually customize all those values, however for the port I prefer to use the web interface.
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:
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.
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.
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.
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:
The are some limitations for the VCSA, the following vCenter Server features are not supported:
- 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.