Running 4.1 VC on a VM

[spf62]

Hello all,

We currently are running our VCenter 4.0 on a physical server, with MSQL 2005 residing on the server.

We are looking to upgrade to 4.1 and have heard that we should put that on a VM. We will be putting SQL 2008 on, which will also reside on that VM

I read that if it's on a VM, we need to disable DRS?

Is this true and if so, why?

any help is appreciated

thanks

[Troy_Clavell]

yes, you can run vCenter as a VM. However, I see no need to disable DRS. Let it load balance in the cluster as the rest of your guests do. I would say, if using HA, set the restart priority to high.

...on a side note, in not already known. 4.1 is 64bit, so a 64bit OS and DSN are needed.

[spf62]

That's very good to hear.

We planned on it being 64bit.

Can I run my VC as 4.1 if my hosts are ESX 4.0?

[dtracey]

Hi there,

Have a look at this document:

http://www.vmware.com/pdf/vsphere4/r41/vsp_41_esx_vc_installation_guide.pdf

Page 97 - Install vCenter Server in a Virtual Machine

Yes - you can run vCenter 4.1 with 4.0 hosts.

Dan

[Troy_Clavell]

Can I run my VC as 4.1 if my hosts are ESX 4.0?

you sure can.

[spf62]

Ok.. this has brought up a few questions regarding protecting the VC.

In addition to nightly backups...

What happens if the LUN the VC is on goes belly up? yes I know they say this will never happen, but it does lol

Also, are you replicating your current VC to another one, on another LUN. If so, what methods are you finding to be the best?

[Troy_Clavell]

IMHO, you should protect your DB instance. Therefore, do not install SQL on the same box as vCenter, regardless of whether or not it's physical or virtual. The DB is still the "meat and potatoes" of vCenter, you need to protect it. Ensure you have good backups that are stored somewhere other than local, if you have to install SQL on the vCenter OS.

As for protecting the actual VM. To me, it doesn't matter, you can deploy a new VM and connect back to the existing DB, in probably less time it would be to restore from backup.

If vCenter would go down for any reason, all your ESX Hosts, and their guests would continue to run fine. The only feature you would lose is vMotion/DRS. HA will continue to function as it is not dependent on vCenter after the initial configuration.

[spf62]

These are all great suggestions and I appreciate the promptness.

Just trying to keep all my bases covered, along with my a$$!!

[hicksj]

Agree 100% with Troy. Forget about the vCenter VM... and worry about the DB. You can rebuild a scratch VM, install vCenter, and point to the existing database very quickly. There shouldn't be any need to backup the vCenter server itself (assuming your database is not running local).

[rickardnobel]

Is there nothing valuable on the vCenter server itself? That is, if I just create a new server with a correct DSN, then everything should work?

(Assuming the vSphere Clients attaches to new vCenter server if the IP is new.)

[KNardi]

Another question:

Would it be fine to have the SQL database on VM also?

We have a seperate dedicated 2008 SQL server that is a VM.

[Troy_Clavell]

Would it be fine to have the SQL database on VM also?

We have a seperate dedicated 2008 SQL server that is a VM.

Not a problem at all. A couple things you might want to consider. One would be if using HA and DRS is to set the restart priority to high for your VCMS VM and your VCDB VM. Also, you may want to create a DRS rule to "keep virtual machines together"

[spf62]

Very good Troy!!

thanks a lot for your help

[dgrace]

One idea is to set the DRS automation level for the Vsphere VM to manual so that you know which host it will be on. For a while we had issues with the VC service auto starting on bootup. Knowing which host it will be on makes it easier to find with connecting a client directly to the known host. With just the 1 (or 2 if using a separate DB VM) DRS can work around it.

[Gregbl333]

My personal opinion is to keep VC on its own physical box. We ran VC as a VM for a long time. There were a few times when we had issues with our VM environment and we could not access VC, which made it much harder to get back up and running.

If you do decide to go VM, make sure you have some solid policies and procedures for managing it.

[spf62]

hmmm, I understand that was the recomended way to run a VC before, but I thought they (VMWARE) recently recommended the VC become a VM?

[rob_nixon]

Does VMware officially RECOMMEND running vCenter Server on a VM, or is this only a supported option? I've been reading the latest VMware white paper, titled "VMware vCenter Server Performance and Best Practices", and that document lays out the option of running on a VM, but does NOT specifically recommend it.

Our manager went to VMworld, and came back saying that a VMware engineer told him that we SHOULD be running vCenter on a VM. We have a test vCenter server running on a VM, and that works fine, but it is running on a different ESX cluster that the lab test host servers it is managing.

We have had large-scale SAN failures (most recent 53 terabytes data lost), which resulted in total loss of over 200 VMs. I'm concerned about the risk of losing the vCenter VM and the difficulty of re-creating vCenter before we could even start working to recover user VMs. Would this entail building a Windows server from scratch (about a full days work, more or less), and then installing vCenter, or is there a better way?

The database (SQL Server) is on the same SAN, and we were just lucky that we didn't lose that. Database is backed up (Tivoli Storage Manager), but time to restore during a large data loss disaster is uncertain.

I would like to hear from anyone running vCenter on a VM in a large environment (about 700 VMs, 200 of which are production) I understand the benefits, but what are the risks and pitfalls of vCenter on virtual machines?

[spf62]

Not to turn this into a pissin contest, but I was at VMWORLD and a VMWARE Engineer told that they recommend the VC be VM.

So that's where my info came from.

Plus the numerous posts from actual VMWare admins, stating that they have been running VC on a VM for a while and it works just fine.

Our site isn't quite as big... we are only running 28 ESX hosts with about 400 VM's, 180 prod, the rest are test/dev.

We are using HA/DRS and DPM.... which is awesome by the way.

I was originally having a hard time myself, wrapping my head around having our VC run on VM.

I thought...hmmm what if the SAN goes down, what happens to my VC.

Well if the SAN goes down, so don't the VM's. At that point the VC doesn't matter whether it's physical or VM.

You really don't need the VC to run your VM's....right? The hosts come back, and so don't the VM's.

From what I read and heard from VMWare Admins is: If your VC VM gets corrupt or goes down, just spin up another server, attach to the database (which resides on a seperate VM) and your good to go.

If a physical server goes bad, your spending a good portion of your day rebuilding or ghosting it back then running a restore from a backup.

I like the idea of getting my VC back as quick as possible.

Like anything in this world... nothing it perfect and whatever can go wrong, will!

Being able to adapt, overcome and persevere is the key!!

Lastly, I want to thank everyone that has given thier 2 cents and given me some good info to go on.

I'm off to configure my VC VM!!

To be continued....

[mark_chuman]

Aside from the problems of "finding" the VC if the hosting ESX servers have problems you should try to "virtualize" your vCenter box. We moved to VM vCenter servers late last year (from physical clustered servers). We could have probably made a case to keep it physical, but it boiled down to doing what we are trying to convince our customers to do, which is "go virtual". One word of advice is pay close attention to %RDY for your vCenter VM (in perf GUI with ESX 4.0). Anything over 20 to 30 should be investigated as performance issues in vCenter start if %RDY hits 30 or above.