vCenter and the physical/virtual argument in 5.1

[mhashemi]

We currently have a physical vCenter server and I'm planning to argue for a P2V of it. I'll be discussing the issue with one of our architects next week and would like to go in with some good, current info. What that in mind, what have you read / experienced that make you a proponent or opponent of a virtual vCenter?

I'm told that one of the arguments against a virtual vCenter has to do with losing connection to the dVS. Can anyone speak to that risk specifically (I think he's worried about isolating the vCenter VM, on the network)?

Thanks.

[Troy_Clavell]

Either or is not a bad choice.  We run vCenter as VM and have never had issues.  It's protected with HA/DRS.  We also run our VCDB as a VM as well.

Plus, if you're going to virtualize, why not eat your own dog food and virtualize vCenter?  It's an easy win!

[weinstein5]

Troy said it all!

[mhashemi]

This doesn't address the concerns about managing from the inside. What about the risk of isolating vCenter?

[Cory_S78]

Use DRS affinity rules to control where the VM lives, this should limit the "what host is vCenter on" game in case of a true disaster/total environment outage. Otherwise, last I checked dvSwitching only requires vCenter to make changes, not to run, so vCenter being down is a management issue not a functional issue.

As a consultant I have several environments with vCenter on a VM, so far minimal issues. In many cases, any issues are offset by avoiding the cost of hardware, licensing and maintenance on a dedicated physical host.

The few environments still using a physical vCenter are using it as a secondary role on the backup server, since connecting to tape drives from a VM is still a problem.

[Josh26]

The ONLY risk whatsoever, is FUD from people who don't know better.

The few environments still using a physical vCenter are using it as a secondary role on the backup server, since connecting to tape drives from a VM is still a problem.

I used to have a lot of environments like this - until I found Backup Exec upgrades routinely trashed the vCenter database and decided BE and vCenter just couldn't cohabitate.

[Gortee]

Great question.  I have been running virtual vcenter for a few years now on multiple clusters and I love it.   There are a few issues around running virtual vcenter as suggested:

1. VDS issues you mentioned.  This is an issue where you need virtual center to provision ports on the VDS on a host but vcenter is down so you cannot provision ports thus you cannot power on vcenter.  This is solved by making the port group for vcenter on the VDS Ephemeral see the blog post here for more info.  This can also be solved with a standard switch for vsphere if your worried.

2. Large clusters and vcenter:  Assume you lost your vcenter and it did not start up how do you know what node is running vcenter.. so you can manually start it up?  This was more of an issue before I did the ephemeral switch.  You can solve this in a number of ways.   You can use affinity groups to lock the vsphere host down to a few nodes so you don't have to go looking like crazy... just plan around multiple power domains if possible.   You can write a script to check regularly for vcenter and email you where it lives.  Honestly I don't have many issues with this matter anymore but just in case there are the options.

3. Database.  If you database is a physical server make sure it's redundant (we use oracle rac so we have little issues on this matter)  but if your database is on a seperate server take into account the port group issues from #2 and start order.. (you want the database up before vcenter)

4. Host Isolation response - assume you have a situation where the ESXi server running vsphere becomes network isolated (like it's nic chooses to stop talking) but is no cluster isolated (datastores are still writable by the host)  You may have vcenter stuck on a node with no way to leave without a forced power down.  (Yes it's happened before thanks HP G7 blades and emulex.)  So you might want a power off response on vcenter.  Because if it powers off then you can manually power it back on

Pro's of virtualizing vcenter:

1. Snapshots before upgrades... along with database dumps will save your bacon

2. Vcenter is not required for HA (vm's will fail over without vcenter)

3. Vcenter is not required for normal operation (other than VDS provisioning) so if it's down its just new operations that are effected

4. All the advantages of virtualization (storage vmotion, hardware independancy, vmotion)

One point of note is I would avoid p2v'ing vcenter if possible.  As long as the database is on another host do a fresh install and connect to it.. it will be much cleaner.

Let me know if you have additional questions.

Thanks,

Joseph

[COS]

"One point of note is I would avoid p2v'ing vcenter if possible.  As long as the database is on another host do a fresh install and connect to it.. it will be much cleaner."

You beat me to it!!!!

Also, *IF* it's possible, get another old host just like the physical one your vCenter is on, and scrape up a few $$$ for a "Standard license" or a less expensive "Essentials Plus Kit" [http://store.vmware.com/store/vmware/Content/pbPage.vSphereComparePage] and use those 2 hosts in an HA cluster and put your vCenter server in there. :smileysilly:

That should ease their minds on their worries.

[mhashemi]

Thanks for all the feedback.