vCenter 4.1 Database Recovery Model Defaults

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

Important bit:
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.

Going to VMworld Europe 2010 Contest: Where is Christian?

Today I finally got word that I will indeed be going to VMworld Europe 2010 in Copenhagen!

I’ve done the registration process, so all that remains is to book the flight and hotel and I’m ready to go.

To celebrate this, I’ve decided to announce a little contest;

Where is Christian aka h0bbel?

The first person to find me, as in the physical me, in the Bella Center during VMworld Europe 2010, (I’ll be there Tuesday – Thursday) will receive a free copy of the Trainsignal VMware vSphere Pro Series Training Vol. 2 training package. No strings attached.

All you have to do is find me and say “Hi”. :-)

See you all there, and no I won’t be wearing a red and white striped sweater and a beanie. I think.

VMware vSphere Hypervisor Licensing and Cost

We all know, and love, the fact that vSphere Hypervisor is free of charge. The free version doesn’t come with all the bells and whistles of the fully licensed product, but it’s still very usable in many scenarios.

Recently I’ve been investigating the possibilities of running vSphere Hypervisor on a number of floating branch offices, also known as vessels.

I’m not going into details about the proposed setup, and how we intend to roll it and so on, but one of the things I really wanted to get out of this was to have all my off-site vSphere Hypervisor installs appear in my vCenter Client. I don’t need HA, DRS, DPM or any of the other licensed features and I’d be happy with running the free edition if only it was able to connect to an existing vCenter installation.

Sadly, and understandably, this isn’t possible in the free edition so I looked into what it would cost to license the installs to make this a possibility. After investigating a bit, it seems that I would need to buy VMware vSphere Standard licenses for all the vessels to be able to get what I want.

For 20 vessels, with the standard pricing available on, inclusive 1 year support, we come up with this (all prices in USD)

Hosts vSphere Standard
License Cost incl. Support
Total Cost
20 1318 26360

In effect, this means that I would need to pay $26360.- USD to be able to get my vSphere Hypervisor hosts connected to my existing vCenter. That simply isn’t feasible in the current situation.

Remember, I do not need any of the other features that vSphere Standard provides me with, like Thin Provisioning, High Availability, vMotion, vStorage APIs for Data Protection and Update Manager. Update Manager could potentially be useful, but that’s about it.

So, dear VMware; Have you considered this scenario at all? I’m sure I’m not the only customer looking to deploy vSphere Hypervisor in remote locations, where they will run a single VM and their poor admin wants to be able to have them all managed in a single console?

I would really like to see a “vCenter Connector” license for vSphere Hypervisor, that only provides a way to connect to an existing licensed vCenter instance.

Is this to much to ask for? I understand that VMware want to get paid for their enterprise products, and I’m normally happy to do so, but in this case the return simply does not warrant the cost.