I am running as VC as a VM on a VMWare Server(not ESX).Thus eliminating the link between the managing VC and the managed ESX machines.

This approach lets you enjoy the benifits of the virtual hardware while not putting all your eggs in one basket. VC VM itself is stored on a SAN and easily migratable to another VMWare Server(scripting) in case of a failure of the physical node.

NOTE TO ALL

1) You don't need VC to manage HA recoveries - VC is like any other application running on VMware, it is abstracted from the hard work going on beneath it.

2) If VC is running on a physical server and that physical server dies, then whilst you are taking time to recover it you find an ESX Server host has died - just to back up #1 above, your VMs running on that host will be recovered by HA even though VC isn't available and is being recovered

3) If VC is running in a virtual server and the underlying physical server dies, then the other hosts in the cluster will manage the recovery of your VC VM within minutes.

VC in a VM has been a head block for years - time to get over it, people, there are no excuses not to run VC in a VM anymore... let's all move on to the next hard problems

I don't disagree with that.  Again, our VC is a VM, but we had some issue twith HA and DRS that scared the crap out of us and made us jump the gun on moving it to a physical box. Being VMWare noobs ,we budgeted for the hardware, but after attending VMWorld and getting a better understanding of things made us rethink it.  For now we will leave it as is.

I'm a VMware expert and having been running ESX for more than 3 yrs in an

enterprise production environment.

I don't run VC on VM for one reason. In our environment, we need 99.9%

uptime on all monitoring and management tools for all production systems. The

only way I would or any enterprise environment should ever put VC on VM is in a

MSC VM environment. We don't run MSC on any VM's so we would have to dedicate

two phy servers to for ESX MSC clusters. Since we don't run MSC on VM i'm not

inclined to dedicate two phy servers just for run VC.

I have a phy server with total redundancy. Dual power supplies connected to

two power strips connected to two separate circuits. As all enterprise

datacenters should be. RAID on the drives, Dual fiber cards each connected to

two fiber switches that in turn have dual paths to the SAN. Dual NIC's each

connected to two network switches. The SQL DB is backed up three times a day to

disk on the Backup server and then to tape at nite. I have a VM clone of the

phy machine in case the VC phy server catches fire. If there's an issue with

VC, I can have it up and running within about 10 mins. I've done D.R. testing.

If I were running MSC on VM and had at least a pair of ESX servers

setup for MSC VM's in production then, I would virtualized VC. I see VC as an integral

part of my Virtual environment and it's my eyes into it. I want it up and

running at all times. When an ESX server and VM work as they are supposed to

then there wouldn't be any issues with ANY VM's. But, the reason we all have

jobs is for architecting and environment that minimized down time to the most

smallest detail that our business needs lets us. Warehouse needs to be up and

running at ALL times. We cannot run into a scenario where VC is virtualized,

the ESX server goes down and the VC Guest is unable to start after HA moved it

to another host and a warehouse Guest on a running ESX server is having

problems. I know have two issues i need to deal with. Finding the warehouse

guest in my 26 host environment and getting VC up and running A.S.A.P. along

with dealing with day to day activities. This scenario is not acceptable in our

environment.

That being said, it all depends on your budget and on business needs.

If business says no down time and the budget is there then, design and environment

to cover all possibilities. If not, try to cover as many possibilities as

possible. If you are working with a small environment and the budget isn't

there make sure all parties understand the possible out comes to scenarios and

the implicated down times.

Ok, i'm rambling now ... lol    ... hope everyone has a great New Year. Be safe and live life ... make it a life to remember.

I was frustrated and had spent way too much time on the

issue. While I intended to follow-up, other priorities came up and I

never quite got back to it. In January, I had the privilege of doing a

joint presentation with Chris Sator from VMWare for an Electrical

Distribution companies conference. I mentioned the problem to Chris,

and he suggested that at this point it may be best to simply rebuild

the server. So I did. And, lo and behold, everything works just fine

now.

-

sanju

Online Dating

Well...you can add my opinion to the "why the heck not" stack.

I mean...I run a true enterprise environment, and I must have 24/7/365 access as much as the next...but if I have my VC database living on a Oracle 10G RAC and I have beter than N+1 redundancy in my hosts and I have solid backup methodologies...please inform me how I'm going to "suffer" in the event of a VC outage strictly due to virtualizing my VC server? I mean...how am I at any more risk than I would be on physical hardware? My database lives elsewhere and I can rebuild my VC in a matter of less than an hour. Whoopti-do...no DRS for a bit...no machine deployments for a bit...and I don't rely on VC for performance or other forms of monitoring anyway. For us it's just a no-brainer...besides...we need the stinkin' power freed up by getting rid of another underutilized box in our datacenter...