Upgrade procedure with new management server

[Allsopp]

I currently have 3 hosts running 3.01 and a 2.0.1 management server with SQL 2000

I plan to upgrade the existing hosts to 3.5 and create a new management server running version 2.5. Here are my plans. Please advise if I've got any mistakes in here.

1) Backup database

2) Upgrade management server to 2.5 (this will toast existing licenses but everything should still run for 14 days)

3) Backup database again

4) Build new management server and install SQL

5) Import database

6) install version 2.5 using existing database

7) upgrade hosts to 3.5

😎 install and apply new licenses

There's also a SAN and fiber switch expansion, as well as 3 new hosts for fresh installs of version 3.5.

Are there any gotcha's in this process? Obviously the existing hosts will be in maintenance mode for the upgrade. Will DRS still work between a version 3.01 and 3.5 hosts?

[RParker]

2) Upgrade management server to 2.5 (this will toast existing licenses but everything should still run for 14 days)

This should be fine, why do you think it wil toast your license?

And what's with the multi backup? If you are going to blow away the server in step 4, why upgrade it?

If it upgrades successfully, you should be fine. You should backup before you even start, but 1 backup should be sufficient, and obviously you are pointing your database to a NEW SQL 2005 instance, not upgrading the current one right?

And just to confirm your SQL 2005 Server should be an a separate host, you aren't trying to put SQL inside the same machine as VC where they run concurrently are you?

> Are there any gotcha's in this process? Obviously the existing hosts will be in maintenance mode for the upgrade. Will DRS still work between a version 3.01 and 3.5 hosts?

No, just know that there are 2 versions of the client. When you connect to a 3.01 machine your client will still use 2.0 even though you upgrade to 2.5. And your 3.x and 3.5 servers will use DRS with no problem. I had ours working like that for a few days.

Other than that, you have an excellent plan.

[rnourse]

I second the warning... steer clear of SQL and VC on the same box!

[Allsopp]

I have been running VC and SQL 2000 on the same box for a year.

What are the reasons to stay clear of this?

[rnourse]

Performance... I've already had a couple of customers who started out fine but things just gradually slowed down. After 12-18 months it was so dog slow I couldnt stand it. The customer on the other hand had just gotten used to it. When we split the two pieces apart everything suddenly became snappy again. They couldnt believe how much faster things happened.

Mind you its pretty easy to fix... leave the old db up and running but stop the VC service. Install a new vm with VC on it, give it the full ram allocation and point it at the same back end.

[jhanekom]

There is no absolute requirement to run VC and SQL on separate servers. As you've noted, some people prefer to avoid this for fear of having these two services step on each others toes in terms of performance, but there is no absolute requirement.

There are currently some issues with upgrading from VC 2.0.x to VC 2.5.x, especially if you're running SQL 2000. These KB articles describes one of the issues:

- http://kb.vmware.com/kb/1003346

- http://kb.vmware.com/kb/1003391

- http://kb.vmware.com/kb/1003052

I'd also urge you to review the following threads before proceeding:

- http://communities.vmware.com/thread/117075

- http://communities.vmware.com/thread/119070

From what I can tell in the forum and my own experience, clean installs have been very successful, but upgrades that attempt to preserve database content less so.

Also build contingency into your plan in case the ESX upgrade fails and you need to re-install the hosts. I've seen posts (but haven't investigated them) about PSOD's or failed root mounts after folks have upgraded from 3.0.x to 3.5.

[Allsopp]

After reading through the suggested links I think I will revise my plan and go with fresh installs. There seems to be many issues than can prevent a successfull upgrade and in my case this can be avoided with a fresh install.

My DRS and HA setup is quite simple and probably less than 4 hours work to re-configure. The current hosts have 2 dual core CPU's and 40Gb of memory so two hosts are more than capable of running all the VM's while I re-install one.

With all the migrations I've done recently I do have some spare hardware so I will try the VC and SQL on separate servers so that the M$ software can use all the resources it wants without affecting VC.

Thanks to everyone for all your help.

[azn2kew · Accepted solution]

There are things to consider when building or upgrading new ESX clusters.

1. Systems downtime requirements (how long can it be down)

2. Redunduncy (SQL cluster, HA, DRS, VMOTION-SAN) these features takes place when you implemented highly redundant infrastructure.

3. If you have the luxury to do clean install, its the best way and its very quick to deploy especially you have just a few hosts to worry.

a. Acquire new VI 3.5 license file by access to vmware.com and redeem them or call VMware support to make sure your license is valid.

b. Download all the new patches for VI 3.5 because it deals with license problem and this should be resolve when you patched it.

c. Decide if you want SQL cluster or standalone if so just load VC 2.5 on top an existing standalone SQL server if that doesn't hold any other DB instances. (all in one is fine for this small environment) But like I've said for redundancy SQL cluster is away to go.

d. Always do backup on SQL databases, VMDKs and etc.

e. Decide you going to share existing LUNs for new ESX host or create new LUNs for new hosts.

f. Once you gather all the information and requirements just install it via kickstart or manually install it only takes 10 minutes to complete single ESX install and to configure everything take you approximately 20-30 max.

If you don't want to start fresh install, than do upgrades one by one make sure to upgrade your VC 2.5 server first and keep existing performance data option when you upgrade otherwise you might experience performance data missing. The rest is simple, load your ESX 3.5 up and than configure networking and LUNs pieces and than start migrating those VMs over to the new ESX host and just repeat until you finish.

ALWAYS PLAN OUT AND BACKUP YOUR VMs AND DATABASE!

Azn2kew!