vCenter Server for Linux really for Oracle

I downloaded the open virtualization format (OVF) appliance and imported it into my VMware ESX host using the VMware Infrastructure Client — and immediately discovered that vCenter Server for Linux will not work with any database other than Oracle. The rest of the limitations are not as big of a concern and are generally as expected for a technology preview, specifically missing functionality within vCenter for Linux itself. But the lack of support for a database that comes as a part of nearly every Linux distribution is a major issue.

This caveat would not be as much of an issue if VMware’s vCenter Server for Linux offered support for PostgreSQL, MySQL, or even sqlite, but requiring expensive closed source Oracle database for a technology preview is extremely limiting and, quite frankly, a decision that suggests that vCenter Server for Linux was not really created for Linux administrators, but instead for an esoteric few people that have already purchased Oracle. Perhaps this is just a ploy to drive away the possible Linux customers? Or is this a ploy by Oracle to tie Linux vCenter to Oracle and hopefully boost Oracle adoption? I do not know, but not providing interfaces to standard Linux databases is not the Linux way.

Testing MySQL

Being the Linux person that I am, I did attempt to get MySQL to work with vCenter Server for Linux. First I had to get open database connectivity (ODBC) to attach to my MySQL database server, which required editing a few files and making the necessary modifications for MySQL support. Once I finished doing that I could connect using ODBC to MySQL, but I still needed a database to make it work.

I then started with the database schema for Microsoft SQL and made some changes to the schema and database views to allow the databases to work with MySQL. Whoever said SQL works everywhere is fooling themselves! After an upgrade to MySQL 5.1 I finally had everything imported. Restarting the VMware vCenter for Linux server and looking at its log files showed the failure. MySQL is not a recognized database, and VMware vCenter for Linux died. This was just a bit surprising to me.

So what are the supported databases? Doing a little research on the daemon itself I discovered that supported databases are Microsoft SQL, Oracle, PostgreSQL, and something called Other. I am not sure what Other is but it is not something standard with Linux. Since PostgreSQL was in the list, I decided to give it a shot.

Testing PostgreSQL

Once more I hooked up ODBC to my PostgreSQL server and then, starting with the Oracle database schema, ported it to PostgreSQL. After several modifications similar in nature to the ones for MySQL, I had a database schema that would load into PostgreSQL. I restarted vCenter for Linux and noticed it would connect, but returned a very strange error related to the tables. After checking a few logs, I realized it had to be something inside vCenter for Linux that caused the problem, not a PostgreSQL issue.  Perhaps it is related to the way PostgreSQL case folds, but my tests show there is nothing we can do within PostgreSQL to make it work with vCenter Server for Linux.

Conclusions

MySQL and PostgreSQL can handle the database creations as well as the port of the stored procedures, but you are limited to UTF-8 characters within all string variables (which would impact Cryllic and Asian users of vCenter for Linux). VCenter for Linux does not accept the use of MySQL, it will flat out deny its use. PostgreSQL does not get denied but it also will not work as a database for vCenter due to other errors. Some people suggest using the free Oracle database which is available, but it has size and other limitations and then I would have to support yet another database in my environment.

I can only surmise that vCenter for Linux is not a reality for the general GNU/Linux environment but only for enterprise administrators, who may never need vCenter for Linux as they have Microsoft Windows database servers already. I wonder about the target audience for this endeavor. I own a SMB and I am required to run one Windows server just for vCenter. Ideally I wouldn’t have to do this, neither would I like to run Oracle as Oracle is a very expensive option for an SMB. VCenter is expensive as well, but buying one expensive license instead of two is a money savings for many an organization

VMware: Please implement either MySQL or PostgreSQL support and let me use the GNU/Linux tools I already use!

Index defragmentation on statistics

I will save you some work in what to look for in determining which tables will need index defragmentation – statistics. While we all like the statistics and graphing options available in the VMware Infrastructure Client and virtual appliances that may use the table, there can be a great amount of data in that table and it can quickly become fragmented. A fragmented index in a database is similar to a fragmented file system where the ordering of an index is not in the order of the index.

In my VC 2.5 environment, the VPX_HIST_STAT1 table is the heavy hitter. For this database maintenance, I’m going to start with the white paper entitled “VirtualCenter Database Maintenance” available from the VMware website. Here there is a command to check your current fragmentation level:

USE
GO
DBCC SHOWCONTIG (VPX_HIST_STAT1)
GO

I have modified the command to use the table name, as the white paper is VC 2.0 based on the table name, whereas this example is on VC 2.5. The result will look something like the following:

DBCC SHOWCONTIG scanning 'VPX_HIST_STAT1' table...
Table: 'VPX_HIST_STAT1' (800721905); index ID: 1, database ID: 16
TABLE level scan performed.
- Pages Scanned................................: 505458
- Extents Scanned..............................: 78097
- Extent Switches..............................: 457307
- Avg. Pages per Extent........................: 7.4
- Scan Density [Best Count:Actual Count].......: 22.34% [113183:905308]
- Logical Scan Fragmentation ..................: 3.81%
- Extent Scan Fragmentation ...................: 0.47%
- Avg. Bytes Free per Page.....................: 187.2
- Avg. Page Density (full).....................: 97.69%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

The key takeaway is the Scan Density percentage. The white paper advises that a number close to 100% is good, meaning that the table index in the example above is quite fragmented. The white paper goes on to identify two correction levels for improving the index. Index defragmentation and, more aggressively, rebuild are the standard options to address the index. If the scan density after a index defragmentation does not do enough to improve the index, database admins will have to begin the rebuild process. A caveat: rebuilding requires VC downtime to perform the database maintenance.

By comparison, here the same command on the VPX_EVENT table. This table is busy, but not near as much as the statistics table:

DBCC SHOWCONTIG scanning ‘VPX_EVENT’ table…
Table: ‘VPX_EVENT’ (36195179); index ID: 1, database ID: 16
TABLE level scan performed.
- Pages Scanned…………………………..: 594
- Extents Scanned…………………………: 86
- Extent Switches…………………………: 132
- Avg. Pages per Extent……………………: 6.9
- Scan Density [Best Count:Actual Count]…….: 66.39% [75:133]
- Logical Scan Fragmentation ………………: 6.73%
- Extent Scan Fragmentation ……………….: 98.84%
- Avg. Bytes Free per Page…………………: 150.5
- Avg. Page Density (full)…………………: 98.14%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

This table is in better shape, but is much smaller than the statistics table.

Configure statistics logging level

As virtualization administrators, one safeguard we can perform is to limit the logging levels within the VMware Infrastructure Client. To access the logging levels select Administration menu, then VirtualCenter Management Server Configuration, then Statistics. Here you want to limit the number of high level logging to keep the VPX_HIST_STATx tables in check:

In selecting which level works best for your environment, be sure to identify any monitoring tools or virtual appliances that may read the selected tables. Also be sure to benchmark your database size and index fragmentation to see if you gain any improvements. Identifying the parts of the entire VMware Infrastructure environment that you can keep in maintenance mode will make your job as a virtualization administrator much easier.