Upgrading Virtual Center 2.0 to 2.5

[ucde1]

I have what is hopefully a quick question for you. We tried to upgrade to Virtual Center 2.5 yesterday (in preparation of moving to ESX 3.5 Update 4 currently running a mix of ESX 3.0.1, 3.0.2 & 3.0.3). When we ran the installer it told us that the previous version has used the Master DB so we should use a DBA to copy records to new database before we upgrade.

I'm not a DBA, but, here's my question, If I was to backup the master db and restore it to a different name, re-point the VMware System DSN (ODBC link) to this new DB can I go ahead with the upgrade?

Do I need to do anything else to the DB before it is upgraded? Our Virtual Center Server is currently running on Windows 2003 Server with SQL 2000.

Any advice is much appreciated.

Regards,

Eoin

[admin · Accepted solution]

If you are using windows authentication or "sa" account, you just have to restore the contents from master DB to a new database and reconfigure the DSN to use the new database. Else, you have to make sure that the use has the same set of privileges on the new database too.

-Sandeep

[MauroBonder]

This is a guide to the process of
updating VMware VirtualCenter. Its intention is to give an overview of
the steps involved rather than going into too much detail, as this can
vary from version to version.

1. Download media from VMware website. ZIP or ISO.

2. Read the release notes.

3. Backup existing VirtualCenter database.

4. Make note or print off a list of which ESX server each VM is on (incase console access or VM modification is required during upgrade).

5. Backup license server files in C:\Program Files\VMware\VMware License Server\Licenses

6. Start the VirtualCenter installer which will detect the already installed programs and will upgrade them. You will need to have the database details to hand (username and password) to update the database.

7. Reboot the VirtualCenter server.

8. Login into VirtualCenter and check the version/build number is now updated.

9. Test that all functionality is working correctly.

</div>

**If you found this information useful, please consider awarding points for

"Correct" or "Helpful"**

[ucde1]

Thanks Sandeep, I'll give that a go so.

[ucde1]

Thanks for the response Mauro but question was really looking for information about moving from the "Master" db. Our current / orginal installation is using the "master" DB.

Anyway I think Sandeep has answered my question. So thanks anyway.

Eoin

[ucde1]

Backed up Master DB and restored to DB called VCDB, stopped Virtual Center Service, re-pointed vmware DSN to VCDB (instead of master), started Virtual Centre Service, checked functionality looked good. Ran Upgrade, worked fine. Checking Functionality as I type looks good so far. Some new warnings about "no management network redundancy" on our various clusters. vMotion between hosts working.

Thanks for the help.

Eoin

[olegarr]

"re-pointed vmware DSN to VCDB"

I would check SQLs "active connections" and verify that you are really using your new DB (not master) and assign username for this SQL DB.

Check this one out:

olegarr

[ucde1]

Hi olegarr,

Scared me with that post! Not sure how to check this but what I did look at was "Process Info" in the Enterprise Manager. There are connections to both "master" and "vcdb" which I think is correct. I had a look at the vpx log file and this does not have the error msg as described the knowledge base article. However I did notice that the latest entry in this log file is from sometime yesterday so maybe I'm looking at the wrong file - c:\windows\temp\vpx\vpx-X.log.

After the upgrade completed and I'd checked functionality I restarted the Server to ensure that all was OK - it was. Only issue I have now is the warnings I now have on all my clusters :

"Host XXX currently has no management network redundancy"

Thanks Anyway.

Eoin

[admin]

Hi,

That is a valid message. You are getting that because you

have only one Service console port. It is advisable to have more than one

service console port.

Hope this helps

-Sandeep