Virtual Center on same cluster it manages? (aka chicken/egg scenario, aka Will it all end in tears and cannibalism?)

[RichDagenais]

My customer wants to deploy virtualized Virtual Center on an ESX cluster that he is managing with the same Virtual Center instance. To be clear, Virtual Center is virtualized, with the database residing on a dedicated SQL machine - also virtualized.

VC (the chicken) will manage several clusters across the enterprise, including a 2 x ESX host cluster (the eggs) the VC vm will be running upon.

The VI management suite (omellette?) also includes VMware Update Manager, VMware LifeCycle Manager, VMware Enterprise Monitor (nworks). All of those are VMs, on same cluster. The rest of the management infrastructure - e.g. HP OpenView - is off-board (physical boxes, for now...)

I have recommended a dedicated management cluster, but the client wants me to prove that the abovementioned architecture is not supported. The documentation regarding virtualizing VC does not cover this particular scenario, although one could infer, as my client has, that above is A Good Idea.

Of course, I am not asking how to deploy VC virtualized; I know how to get a chicken to sit on an egg. Unfortunately, the notion of feeding the chicken to the egg is ruffling my feathers.

I realize that of course when everything is live this will work. But there are scenarios (like a system shutdown) where it will be problematic, and it just seems like A Bad Idea to me. For example, in order to shut down the cluster you would have to bring down the whole VI management suite and the SQL server and then proceed to use the VI Client (well, I'd use ssh) to bring down your hosts. And then in reverse on power-up. And of course, since VC is down throughout, so is the nWorks SPI and by extension OpenView is going to be blind to all this.

As a rule, I place management segmented from services. But I can't find any "best practices" that state this seemingly obvious approach. A philosophical debate is not what my client wants; he wants something more substantial. I'm sort of irked to have to prove a negative, so forgive me for sharing this burden.

I would like feedback from the community; have you done this? Am I wrong to recommend otherwise?

[weinstein5]

There is no problem with VC being virtualized on an ESX host it manages and with that host being a part of the DRS/HS cluster - HA does not require VC running the HA failover functinality is pushed down to the ohst memebrs of the cluster - and if the server hosting the VC virtual machine fails all the other vms will continue to run because VC is soley a proxy for managing the hosts - you will lose VC functionality such as DRS, vmotion, update manager until the VC server is back up - for DRS since you can vmotion a virtualized VC server DRS will still work -

[mike_laspina]

Hello,

Yes I know how you feel. I was very skeptical at first as well. What convinced me initially was a call to VMware support and the responce was .... fully supported!

Since then it's VM'd and I like it ... no more fear of the unknown.

[Jinxy]

Rich, unfortunately nothing to add to help your argument.

I just wanted to add that I could not have put your situation any better my self and like it as I have a similar issue. Like the others mentioned and especially Mike where VMware state it is fully supported I am now contemplating P2V'ing my physical VC management server into the VM world for a specific customer.

I found it hard to take on the concept of running the VC within a VM but everyone appears to be heading that way so as the phrase goes, "if you can't beat em join em" LOL.

Also the fact that it will give me the additional functionality that comes from being a VM, ie easy recovery from backup and snapshot facility etc I think it's now worth a punt. I need to add I am easily led though LOL.

Good luck though.

[matuscak]

We're running VC in the cluster it controls. It's a two host cluster, and like other folks have mentioned in the forums, HA is kind of wack in this configuration (apparently) as of update 2. It fairly frustrating. If the power dies, when it comes back, the servers boot, the SAN starts, but none of the VMs boot. I've been using the web interface to connect to the host with VC on it and power on the VC VM. Once VC wakes up, the rest of the VMs power on. I'm really hoping there is a fix for the HA problem soon. I've been toying with the idea of setting up another server running ESXi and just having the VC run on it.

All that being said, if HA is working, I'd be willing to keep VC in the cluster. I like the idea of the hardware redundancy and the VMotion mobility.

[RichDagenais]

You will also lose all the monitoring functionality, LifeCycle Manager, etc. Everything that latches on to VC breaks.

But otherwise I can only think of one scenario - full shutdown - where this will be an issue. We would have to set the whole VI to "maintenance mode" in HP OpenView before shutting down the VEM, VC, the supporting SQL instance, and ultimately ESX.

I'm aware of all the other points you made, and I concur that virtualizing VC is fully supported (see: http://www.vmware.com/pdf/vi3_vc_in_vm.pdf ).

I think its safe to say this is primarily a philosophical/best practice problem not a technical one.

Thanks for the input!

[RichDagenais]

I found this link relevant, if a bit outdated on some points. http://vmetc.com/2007/12/28/should-virtual-center-run-as-a-virtual-machine/