How to size VMware View Composer database is a common customer question and I have recently seen it once again in on of the internal discussion lists. Unfortunately, VMware does not have an official number for View Composer and Event database sizing.

However, some of VMware EUC Technical Enablement guys have adopted a ‘standard’ that seems to hold up very well  across VMware View 4.6 and 5.x installations.

VMware View Event Database: I previously extensively wrote about the Event Database and explained what goes in there. You can find my article at VMware View 4.5 Events Database Explained. In my article I wrote:

The size of the Events database is dependent on number of users, amount of login/logoff, number and frequency of refresh and recompose operations etc. Fundamentally any action or task in VMware View Manager that happened either through manual intervention or automated process will be logged and recorded.

VMware has not published sizing information for the Events database, therefore any numbers I demonstrate here are purely based on my tests and experience deploying VMware View.

On average, during my tests, each desktop consumed 2.5MB of database storage per month. Although it is possible to specify the amount of time to show the events in View Administrator, the data in the historical databases are never deleted and will always be available for external queries.

When sizing the Events database be sure to accommodate requirements for 2 or 3 years of historical data. The math is rather simple: 250 users x 2.5MB x 36 months = 21GB

According to the EUC technical enablement team my numbers were very accurate.

VMware View Event Database: 2.5MB per Desktop per month. 1 to 1.5MB seems to be more accurate but it really depends on how dynamic the environment is – how many refresh, logoff and recomposes are occurring)

If you would like to reduce the size of the event database just change the Event Settings in VMware View Admin Console:

VMware View Composer Database: 5GB total.

According to tests and field experience the Composer database should never get even close to 5GB.

Thanks to Rasmus Jensen for providing such useful information.

This article was first published by Andre Leibovici (@andreleibovici) at myvirtualcloud.net.