Valentini
Enthusiast
Enthusiast

Infrastructure 3

I am looking for some basic information any assistance is appreciated:

Can Virtual Center 2.5 manage 3.01 and 3.02 ESX servers that have existing VM's running on them without upgrading them to the most recent version of ESX?

What type of performance increase can I expect to see if I upgrade to Infrastructure 3?

Is it possible to manage 50-75 ESX hosts via Virtual Center that is running in a Virtual Machine? Any thoughts? (vs physical server)

Thank you,

Valentini

0 Kudos
13 Replies
Troy_Clavell
Immortal
Immortal

Valentini,

This link is probably the best place to start. I know that VC 2.5 can manage 3.0.2 HOSTS.

http://www.vmware.com/support/pubs/vi_pages/vi_pubs_35.html

0 Kudos
Valentini
Enthusiast
Enthusiast

I somehow blew right past the matrix link on this page the other day. Thanks for the reference.

Any thoughts on running VC in a VM?

0 Kudos
Troy_Clavell
Immortal
Immortal

VC in a VM is supported by VMware.

That being said, our VC enviornment is running on physical hardware.

0 Kudos
EdiB
Enthusiast
Enthusiast

Valentini,

I am actually managing ESX 3.0.1, 3.0.2 and 3.5 from Virtual Center 2.5.

I haven't been able to upgrade all of my hosts to 3.5 yet.

You don't have to upgrade them to manage them from VC 2.5 all you need to do is add them to VC 2.5 and the VC agent will be updated to the new version so you'll be able to manage them all from one VC.

I have upgraded 3 of my hosts from 3.0.1 to 3.5 and as far as performance I really don't see much of a difference but there are the benefits of the new 3.5 features which I like to take advantage.

I have 13 hosts and I am managing them all from a virtual center which is sitting on a physical server.

you can manage them via vm if it has a lot of resources but it is not recommended cause if for some reason you ESX host goes down then your VC will go down so you can't manage the rest of the machines.

As far as performance it wouldn't be an issue as long as you assign a lots of ram and CPU resources.

Please let me know if this answered your questions.

Ed

0 Kudos
Valentini
Enthusiast
Enthusiast

Good info.

Thanks to everyone for their reply....

0 Kudos
Rodos
Expert
Expert

you can manage them via vm if it has a lot of resources but it is not recommended cause if for some reason you ESX host goes down then your VC will go down so you can't manage the rest of the machines.

Just like it would if your physical box went down. However as a VM if it is part of a cluster and the host the VM was on went down HA would restart it on another host. Its one reason why people sometimes like to run VC as a VM. There are pros and cons. I think "not recommended" might be a bit strong.

Rodos {size:10px}{color:gray}Consider the use of the helpful or correct buttons to award points. Blog: http://rodos.haywood.org/{color}{size}
0 Kudos
fontyyy
Contributor
Contributor

Any thoughts on running VC in a VM?I do, it's one of our (boo hiss) Microsoft VMs and is totally fine. Running it on an ESX VM does strike me as a little silly as a situation could occur where in the event of a total shutdown you'd end up connecting directly to the host boxes themselves to try and find the VC "machine" (presuming you're running DRS in automated mode). Then of course you've got to hope it starts without a licence server (as it's probably itself).

Rodos is wrong if the VC (or the VC DB) isn't there, there is no cluster, no HA, no DRS, the ESX boxes themselves are not aware of such things. It's the VC that does all that stuff.

We had a powercut (a long one 8 hours +) and everything went down, when it came back all the physical boxes restarted, all the MS VM's restarted (they're running on local machine accounts), the ESX VM's did not, why?

Because the SQL server the VCDB sits on runs the SQL service as a domain account (as per MS recommendations) and with it tried to start the domain account wasn't available as the domain wasn't there yet, so the SQL server never started even when the SQL service did eventually start. Although there is a setting in services to keep trying to start after a failure (and that is set), that doesn't start the SQL server itself and there does not appear to be a setting to keep trying that.

So with a VCDB any attempt to connect to the VC failed, so I connect the VC client direct to a host and there all the machines were, powered down. Start the SQL server and they all "powered themselves up"? Wrong thought, the VC powered them up.

0 Kudos
Rodos
Expert
Expert

Rodos is wrong if the VC (or the VC DB) isn't there, there is no cluster, no HA, no DRS, the ESX boxes themselves are not aware of such things. It's the VC that does all that stuff.

Well actually, Rodos is right ! If you look carefully at my post you will notice that I mention that the VC VM will restart with HA and this is correct. HA does NOT require VC to function. VC is required to configure and manage it but all of the details for its function are stored on the host in the cluster. Don't just believe me and my experience, review the VMware whitepaper , especially the last topic of "VirtualCenter in a VMware HA Cluster", where it states

If high availability for the VirtualCenter virtual machine is desired, then the ESX Server host on which it is running may be placed in a VMware HA cluster. If that host fails, another will automatically restart the VirtualCenter virtual machine. ...

We had a powercut (a long one 8 hours +) and everything went down, when it came back all the physical boxes restarted, all the MS VM's restarted (they're running on local machine accounts), the ESX VM's did not, why?

Because the SQL server the VCDB sits on runs the SQL service as a domain account (as per MS recommendations) and with it tried to start the domain account wasn't available as the domain wasn't there yet, so the SQL server never started even when the SQL service did eventually start. Although there is a setting in services to keep trying to start after a failure (and that is set), that doesn't start the SQL server itself and there does not appear to be a setting to keep trying that.

Given your description, the reason why your infrastructure did not re-start properly was poor implementation.

I am sorry that you had a painful experience with VC as a VM, but lets stick to the facts rather than speculation.

Rodos {size:10px}{color:gray}Consider the use of the helpful or correct buttons to award points. Blog: http://rodos.haywood.org/{color}{size}
0 Kudos
fontyyy
Contributor
Contributor

As far as our ESX infrastructure is concerened my VC is not a VM (as it's a Microsoft VM) and the "machine" itself did restart, the reason the VC service did not was it failed to contact the VCDB as the network account the SQL service runs under was unavailable, so even connecting the VI Client to the VC failed, no shock there, slighly annoyingly when the SQL service did eventually start (it's set to keep trying) the SQL engine itself did not so the VC service also stayed stopped but that's another matter.

My point is I had dozens of VM's sat there powered down, obviously I could only see this by connecting the VI Client direct to the host (no VC remember?), the minute I started the SQL engine and the VC service they all powered themselves up.

It's also possible HA failed as the failover capacity was exceeded.

This is not speculation, it's fact.

0 Kudos
danpalacios
Hot Shot
Hot Shot

Just an additional thought ...

If you plan to put THAT many hosts into VC, you probably want to run the database on a separate SQL server and it is likely that server should be physical. If the database is physical, then VC should be no problem on a virtual box.

0 Kudos
opbz
Hot Shot
Hot Shot

brief note here.

Running VC on a VM is possible but probbly not recommended for practical reasons and performance reasons:

Practical reasons: seen quite a few people that do this and once they suffer a serious power cut they are completelly unable to do anything. Granted you can power on the server and ocnnect to them and then poweron VMs individually but a lot of VM managers I have seen relly completelly on VC if that VM is donw they are flounderring

Performance reasons: VC can gerenate a lot of logs and can use its DB pretty intensivelly. Specially when its managing a large number of VMs and ESX servers. So it might not be considered a suitable machine for virtualization

0 Kudos
fontyyy
Contributor
Contributor

That's why mine is an MS VM, running the VC (even worse if it's the licence server) on ESX strikes me as asking for trouble, without a licence server you run a risk of no vm's being willing to power up, granted there is a "grace" period when it should power them up anyway but even so I wouldn't do it.

I see with the latest updates VMWare now say SQLExpress is OK for smaller setups, as I've had problems before (see post in this thread) with SQL server itself not restarting after a major power outage our VCB is just running locally on the MS VM. It works and our ESX project was/is to consoldate servers and reduce spending which it's doing very well, I'm hardly going to ask for a server for it!

0 Kudos
opbz
Hot Shot
Hot Shot

you have VC, VCB and license server all on one VM?

Really?

granted License server has preaty minimal impact.

I know VCB and VC where not supposed to be on the same machine. Its on some of the VCB troubleshooting guides that I had.

Also one of the main advantages of VCB was that it can access your VMFS luns through its own HBA. How are you managing this, though iscsi on the Ms VM?

I understand the desire to minimize server sprawl but personally I like having things somewhat separated.. a backup server (not a VM) is I think a great idea. You can use a san attached TBU something that is not yet supported. Also if you are doing lots of backups the traffic through this machine can be VERY high and a VM might have issues with it.

0 Kudos