VMworld Europe 2010 is close. Very close. In fact, lots of people are already in place in Copenhagen, personally I don’t get until tomorrow evening (the 11th).
Since I get in pretty late, I really hope I’ll be able to get to my hotel quickly, and then find Custom House for the Tweetup/VMUG Party.
Remember I have a little contest going, where you can win a copy of Trainsignal VMware vSphere Pro Series Training Vol. 2.
In case you are wondering how to find me, well I’m not really sure how you should go about doing that. Use your imagination!
Photographic proof that the prize exists:
Sometimes leaving the defaults in place might just come back and bite you, hard.
That might also be the case with your vCenter 4.1 database, as I experienced back in July.
All of a sudden my vCenter Server stopped working. The symptoms where pretty obvious, my client couldn’t connect to the vCenter server. Naturally I connected to the server, and noticed that the VMware VirtualCenter Server services had indeed stopped. No wonder the client couldn’t connect to it. I tried starting it, but if would shut itself down again after a few seconds.
The next step, obviously, was to look at the event logs and there it was, in plain English explaining the service desire to stop:
Log Name: Application Source: MSSQL$SQLEXP_VIM Date: 17.07.2010 02:06:16 Event ID: 9002 Task Category: (2) Level: Error Keywords: Classic User: SYSTEM Computer: [removed] Description: The transaction log for database 'VIM_VCDB' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases
The transaction log for database ‘VIM_VCDB’ is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases
As it turns out, the transaction log for my SQL Server Express based vCenter install database was indeed full. Not only was it full, it had grown to eat just about each and every byte out of the disk space on the server.
I got around this by changing the recovery model back to simple, and performing a new backup via the script I’ve mentioned earlier: Scheduling vCenter Backups. I’m not saying this is how you should configure your own vCenter recovery model, you need to chose one that fits your specific backup scheme. Just make sure you understand how the different settings affect your particular environment.
So, where does the defaults come into play?
As VMware explains in KB Article 1001046 : SQL Server Recovery Model Affects Transaction Log Disk Space Requirements the install defaults to the Bulk Recovery model. This model allows the transaction log to grow, until a backup clears it and lets it start over. If you, like me, used a scripted backup that doesn’t do transaction log pruning you might very well be in the same predicament pretty soon.
So, take my advice, make sure you understand the backup routines you have in place for your vCenter and check those log settings before your vCenter stops unexpectedly.
Do yourself a favour, check your log files and do it now.
Of course, this is not the only thing that has an effect on your vCenter Database size. The settings for vCenter Server Statistics also comes into play, but in my case the issue was the backup scheme I had in place and the default settings for a new vCenter 4.1 install.