Pros and Cons for running Virtual Center on VMWare

[Skark166]

We are looking into whether we should build a physical box for our virtual center server (2.5 w SQL 2005), or run it on a virtual machine within our VMWare environment.

Does anyone have a list of pros and cons for running either way? Or maybe offer us some insight from your experience/issues running this way?

Thanks,

K

[dpomeroy]

I think it is a great idea especially with VI3 Enterprise where you can take advantage of HA, DRS, VMotion, etc, plus all the generic benefits of virtualization.

I have had two configs in production, 1. with the SQL server being on the same VC server and 2. with the database being on a separate physical SQL cluster. Performance was good in either configuration.

We have ran in production this way since VI3 came out and have had no issues.

Don Pomeroy

VMware Communities User Moderator

[ctfoster · Accepted solution]

There are a few threads that cover this topic including a post in the link below that addresses your question directly.

{color:#3366cc}http://communities.vmware.com/message/917191{color}

The camps mainly break down into those users that are uneasy with hosting the primary management tool on the system it's supposed to be managing (understandable) and those who like all the advantages that running any system as a VM brings (HA - snapshoting - backup etc etc.)

For my take I run it as a VM under Server and get the advantages of both approaches. Anyway it's not the VI you should be worried about its the database it writes to.

[khughes]

I think it is all what you and your company feels comfertable with. Many people run their VC inside their VMware enviroment which has a lot of benifits. By running it on its own physical box, you have a single point of failure, but also a box outside of the production VMware VM's if something should happen.

We run our VC on a phsycal box but I think that was because it was recommended to us to do it that way. Looking at it now I think the benifits in the long run running it as a VM are much greater than on a physical. You have DRS to keep it with plenty of resources, you have HA incase of host hardware failure, it'll just power on in a different host and then you have the DR standpoint of being able to restore a full box instead of installing windows, then database software, then configuring. The chances that you have a physical problem with a server are usually higher than problems with a san, imo.

- Kyle

[Skark166]

Thank you all for your replys. That was fast.

We've decided to put VC on a VM with an external database. Looks like most of the potential issues that come along with that scenerio are rare and adaptable.

Thanks again,

K

[patrickds]

Just don't try to use update manager to patch the host your VC VM is running on.

If you're planning to use update manager, and want to run VC on a VM, vmotion (and therefore a VI enterprise license) would be almost required, since you need to be able to move the VM with VC to another host when installing patches.

With starter or standard licenses you would have to shutdown the VC prior to patching the host, migrate it to another host, start the VM up again, and then patch the host it was running on before.