I've got a quick question, actually just a validation of an idea. Currently in our 2.5.4 environment VC is a physical box. I am planning on installing VC 2.x in the current ESX environment on a new guest. We aren't upgrading VC, but replacing it.
We are getting new hosts, and once we build one with ESX 3.0.x I am planning on cold migrating the VC guest manually to the new ESX 3.0.x farm. VC 2.x won't be managing any of the 2.5.4 hosts until the day we get ready to do the dMotion to the new evironment. Does this seem logical? Installing VC 2.0 on ESX 2.5.4, and then migrating it manually once we get a 3.0.x ESX host?
I'm not 100% sure about this 'unsupported' statement, but I speak with more people running VC2 as a VM than than used to be the case.
I would recommend running VC as a VM if I also had HA configured within the farm. This way you're covered if the host goes down.
VC on a vm is unsupported and unstable.
At your own risk.
I suggest an upgrade.
It's unsupported? Really? I have read a bunch of posts with people having it installed on a guest. Would seem a bit... ironic.
As for upgrade, that won't meet our project requirements. It has to be a new install either physical or virtual.
I'm not 100% sure about this 'unsupported' statement, but I speak with more people running VC2 as a VM than than used to be the case.
I would recommend running VC as a VM if I also had HA configured within the farm. This way you're covered if the host goes down.
I must correct myself.
It is supported, but I'd never use it on a production environment with SLA.
What happens if the HOST "hosting" VC vm will go down?
an interesting thread:
http://www.vmware.com/community/thread.jspa?messageID=463781񱎥
'What happens if the HOST "hosting" VC vm will go down?'
Exactly the same as if a physical server running VC goes down I guess i.e. you lose VC. Running VC on a VM within a HA cluster gives you automatic restart if a host fails, whch would have to be done by clustering in a physical world....
