Virtual Center Database

[phenrichs]

When you install virtual center a database is required. What exactly does VC use that DB for? Are there serious considerations for expandability of that database, or is there routine maintenance that should be performed? I have a VI3 system that has been up for a year running about a dozen vm's constant. The ESX host has only been shutdown twice in that year for memory upgrades. I have not shutdown or restarted the VC in that year. It has only been restarted when required by windows updates. Are there any database size issues or performance issues that I should look ahead for?

[VirtualNoitall]

Hello,

The VCDB holds configuration and performance data for virtual center. The biggest impact on size and performance will be the level of performance data you keep. We have a very large deloyment so we have a deidacted SQL server with 4GB of RAM, lots of disk space for the db and backups and an 8 disk RAID 10 array.

I would highly recommend setting up reindexing and your standard performance relates SQL jobs ( these can be found in the SQL maintenance wizard ). Database availability and performance have a big impact on VC.

Hope that helps!

[Jae_Ellers]

VC stores everything you see in the client in the database. So relationships about which VM belongs to which ESX server, which server to which cliuster, etc. It also stores all your performance data for a period of time and then performs "rollups" which average the data over time and result in a smaller db.

Keep an eye on the db size. A rapidly growning db or temp db or transaction log is a warning sign.

You can rebuild some indices if you're so inclined, although it doesn't sound like your system is loaded.

My quick check is to do a performance chart for a week or month of data. If that returns within 10 seconds or so I feel pretty good about the db.

-=-=-=-=-=-=-=-=-=-=-=-

Check my blog:

http://blog.mr-vm.com

-=-=-=-=-=-=-=-=-=-=-=-

[phenrichs]

Hey thanks for the help. I am testing a new scenario here as you could probably guess from my other post will include running VC as a vm. This will be pretty small actually. One host with a foreseeable maximum of 12 vm's one of which to be VC, so I don't think it will be too large of an issue as long as there is some sort of cleanup for log files and things like that I think.

Regards,

Paul

[Jae_Ellers · Accepted solution]

Be advised there's a catch-22 involved with recovering a VC as a VM. Should you have to recover the ESX server and recreate the VC you need to license the ESX server before you can create the VC. So you need to keep a host based license file for this purpose.

-=-=-=-=-=-=-=-=-=-=-=-

Check my blog:

-=-=-=-=-=-=-=-=-=-=-=-

[scerazy]

Would the licensing bit from above apply also to a restore of the VC VM from the image (Ghost, Drive Snapshot etc)?

I do not think so, byt maybe I am wrong.

Restore image, restore DB copy & you are back running

Seb

[Dave_Mishchenko]

It wouldn't be an issue for the VirtualCenter service running in the VM itself. If you had to rebuild a host, you wouldn't be able to start up a VM (in this case your restored VC VM) until the ESX host is licensed. But the ESX host can't get a license from the licensing server which is running in your VC VM. Thus as mentioned you need a spare host based license file so that you can start up the VM and then fix the licensing config on the host to point to the licensing server.