VMware Cloud Community
jmay
Enthusiast
Enthusiast

Start fresh with new vCenter 5.5 install vs upgrade?

I've been trying to get my vCenter Server Appliance 5.1 install to migrate to 5.5 OK, but it's giving me headaches.  Some interface elements are missing, I can't get consoles to work, etc.

That said, can I just start with a fresh vCenter Server Appliance install 5.5 instead?  What settings are even stored within vCenter vs. the individual ESXi host machines?  Is this OK to do on a live system?

- John
20 Replies
mofr
Enthusiast
Enthusiast

on vcenter server are stored distributed switches configurations, host profiles, historical performance data and etc.

you can make a fresh install of vCenter Server and migrate all esxi host there but you must carefully plan each step.

my recomendation will be to make an upgrad like it is described here: VMware KB: Upgrading vCenter Server Appliance 5.0.x/5.1 to 5.5 and solve post upgrade issues if they appear. fresh install, always must be last option.

---------------------------------------------------------- MCITP: Enterprise Messaging Administrator MCSE: Messaging VCP4 Blog: http://vforv.me/ Twitter: @sgaldava
Reply
0 Kudos
jmay
Enthusiast
Enthusiast

Ok, but the upgrade you detail hasn't worked properly for me. I'm not using anything fancy about vsphere at all, since I'm running OSX vms than can only do so much. No virtual switches, high availability, vmotion, etc.

I think the only thing I changed config-wise on the hosts were some fibre channel parameters, which I would think are stored in the host itself?  Other than that, all I've done is configure vms.

That said, if I don't care about losing historical performance data, etc. can I just install a fresh version of vcenter, point it to my esxi hosts, and have it work ok?  I would also think all the vm info is stored on the hosts, not in vcenter, no?

- John

Reply
0 Kudos
admin
Immortal
Immortal

installation of new Vcenter server

Installation steps for Single Sign-On 5.5

  1. Mount the vSphere 5.5 installation media. The installation wizard appears.
  2. In the left pane, under Custom Install, click vCenter Single Sign-On and then click Install .

    Note: If any of the prerequisites are not met, they are listed in the right pane under Prerequisites.

  3. In the welcome screen, click Next.
  4. Review the End User License Agreement. If you agree, select the I accept the terms in the license agreement option and click Next.
  5. Review the Prerequisites check screen.
  6. Click Next.
  7. Select a deployment mode and click Next.



    The various deployment mode options include:

    • vCenter Single Sign-On for your first vCenter Server – Select this option to deploy your first SSO server. This server becomes the first SSO server in a new vSphere authentication domain.

      After you select this option:

      1. Provide a password for the SSO administrator user and click Next.

        Note: This dialog shows information related to a domain by the name vsphere.local. This is not a domain that is auto-detected within the existing environment, but a net new domain used internally by vSphere. The administrator@vsphere.local account performs the same function as the admin@System-Domain account in previous versions of vSphere.

        For more information about the administrator@vsphere.local account, see the vSphere Software Components section of thevCenter Server and Host Management Guide.

      2. Provide a site name and click Next.

        Note: The site name is used in environments where there are SSO servers in multiple sites. Ensure to select this name carefully because it cannot be changed in the vSphere Web Client after the installation completes.


    • vCenter Single Sign-On for an additional vCenter Server in an existing site – Select this option to add this SSO server to an existing vSphere authentication domain site. This server replicates information from an existing SSO server in the vSphere authentication domain.

      After selecting this option:

      1. Under vCenter Sign-On Information, specify the Partner host name. This is the host name of the alternative SSO instance.
      2. Specify the password for the administrator@vsphere.local user for the alternate instance and click Next.

        Certificate information for the partner service you provided is displayed and you are asked if you trust the certificate. If you trust the certificate, click Continue.

      3. Select the original site name defined during the installation for the primary node name from the dropdown and click Next.

        Note: Both SSO instances share a common site name. Using this deployment mode is essential for configuring a load balanced HA Single Sign-On implementation.

    • vCenter Single Sign-On for an additional vCenter Server with a new site – Select this option to add the SSO server to an existing vSphere authentication domain and create a new site. This server replicates information from an existing SSO server in the vSphere authentication domain.

      After selecting this option:

      1. Under vCenter Sign-On Information, specify the Partner host name. This is the host name of the alternative SSO instance.
      2. Specify the password for the administrator@vsphere.local user and click Next.

        Certificate information for the partner service you provided is displayed and you are asked if you trust the certificate. If you trust the certificate, click Continue.

      3. Enter a name for the new site.

        Note: The site name is used in environments where there are SSO servers in multiple sites. Ensure to choose this name carefully because this name cannot be changed in the vSphere Web Client after the installation completes.
  8. Optionally, provide an alternative TCP port number for the SSO service and click Next.

    Notes:
    • Changing the default ports is recommended only if you have an unchangeable port conflict in the same system.
    • When using the custom installer for vSphere Web Client, Inventory Service, and vCenter Service, you are prompted for the Lookup Service URL. The prompts default to port 7444. If you change the port number now, you must manually update the port number in all future custom installers that would use this instance of SSO.
  9. Optionally, provide an alternative installation location and click Next.

    Notes:
    • The installation requires 2 GB of disk space to be available. For more information, see the Hardware Requirement forvCenter Server, the vSphere Web Client, vCenter Inventory Service, and vCenter Single Sign-On section in the vSphere Installation and Setup Guide.
    • The path must conform to NTFS naming restrictions. For more information, see the Microsoft article Naming Files, Paths, and Namespaces.

      The preceding link was correct as of September 19, 2013. If you find the link is broken, provide feedback and a VMware employee will update the link.
  10. In the confirmation screen, click Install to start the installation process.
  11. Click Finish when the installation completes.

Upgrading to vCenter Server 5.5 Using a New Server

You may find that you want to start looking at upgrading your vCenter Server to version 5.5 to take advantage of new capabilities, a faster and improved web interface and the ability to upgrade your hosts to ESXi 5.5.

But what if your current server might be for example vCenter 5.1 on Windows 2008R2 with SQL 2005?  You might want to take the opportunity to start clean on more current versions of Windows and/or SQL.  This article is a summary of a process that worked for me as well as a few hurdles encountered along the way.

Before we begin, make sure you also consider the vCenter Server Appliance which is a hardened pre-built vCenter Server running on Linux. Some will desire to run vCenter Server on Windows and if so this post is for you.

This article also assumes SQL is running locally on the vCenter server.  If the database is remote, this article will still work except that either you will not need to move the database, or you’ll be moving it to a different server.

UPDATE:  As this process does not transfer the ADAM database, the existing security roles will NOT be migrated to the new server.  These roles will have to be manually rebuilt unless you want to try some scripts as discussed in this post.  Special thanks to Justin King ( @vCenterGuy ) for pointing out the issue and Frank Büchsel ( @fbuechsel ) for providing the link to scripting permissions import/export!

Build The New Server

The new server should be Windows 2012 but NOT the R2 version which is not yet supported. If you want to use a local database, go ahead and install the database at this point (we used SQL 2012).

SSL Certificates

We didn’t have custom SSL certificates but you will still need to transfer your SSL certs to work with your existing database.  When I got to installing vCenter Server in a later step I encountered this error and had to go back and grab the certs.

On the current vCenter server you should be able to find the certificates in the following hidden directory:

  • For Windows 2008:
    C:\ProgramData\VMware\VMware VirtualCenter\SSL
  • For Windows 2003:
    C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL

Copy everything in the SSL folder and create the following directory on the new server and place them here:

 C:\ProgramData\VMware\VMware VirtualCenter\SSL

For more information see the following KB article on certificate errors related to vCenter Server installation

Transfer the Database (downtime begins)

Shutdown the vCenter Services so that we can transfer the database.  There’s a few options here.  Our vCenter DB was about 30GB so I simply did a detach and copied the DB files across the wire.  If you have SQL 2008 or later you might want to take a compressed backup or look at a tool like Red Gate or LiteSpeed which can compress your SQL backups into much smaller files to transport. Additionally you also might be able to detach the relevant VMDKs and attach them to the new server, allowing you to copy them at disk speed.

Once you have the database running on the new server we can begin with the vCenter Server install.

vCenter Server install

First rule here is the use vCenter 5.5A (build 1378901) which fixes some authentication issues on Windows 2012 in some environments.  Second rule is to install the elements one at a time. I prefer to be able to control each install individually and I’ll address each component below.

vCenter SSO Install

When you install this you have the option to sync with an existing SSO server.  Since the only other server with SSO we were going to retire, I chose the “first server in new site” option.  We will need to edit SSO later on to enable AD authentication but not yet.

vCenter Web Server Install

When I first installed this component I got a 404 from the web server on each attempt.  As it turns out there is an issue described in this KB article such that the web server will return 404 errors when installed to a drive other than C. Normally I try to install everything I can to a non-C drive, but it seems that this component needs to be on the C drive to function properly.

vCenter Inventory Server and vCenter Server

These services are mostly straight forward installs.  If you copied the SSL certificates above you should have no issues in this step.  You will have the option to have vCenter automatically attempt to connect to the hosts or to do it manually.  At this point vCenter server should be working, but only local accounts might be able to login.

To fix this login to the web UI for vCenter using either a local account or the SSO admin account and perform the following steps.

1Browse to Administration > Sign-On and Discovery > Configuration in the vSphere Web Client.
2On the Identity Sources tab, click the Add Identity Source icon.

Add the appropriate source type such as Active Directory and add it as one of the default domains. For more information see the following help chapter on setting default domains.

vCenter Update Manager (optional)

You should mostly be in business at this point but you may also want to install vCenter Update Manager.  With this step there are a few additional considerations.

First of all you need to create a 32-bit DSN for the Update Manager Database.  There’s a KB article here but I think my method was quicker.  On the 2012 server open up the search charm and type “odbc” and press enter.  You’ll see both the 32 and 64 bit versions of the ODBC configuration utility.  Select the 32-bit utility and create your DSN, but…..

Make sure you use the SQL 2008 R2 Native Driver even if you are using a 2012 database.  As explained in this article, the vCenter Update Manager service will fail to start when using the 2012 Native Client.  Use the 2008 R2 Native Client against the 2012 SQL and it will work fine.

That’s basically it.  To summarize take the following steps:

1)  Build a new 2012 Server (not R2) and install SQL or other database

2) Copy the SSL certificates from the current vCenter to the new server

3) Shut down vCenter Server services

4) take backups and/or snapshots as desired

5) Using the method of your choice, forklift the current vCenter database to the new server (if SQL is local)

6) Install SSO

7) Install vCenter Web Server to the C: drive

😎 Install Inventory Manager and then vCenter Server

9) Logon to vSphere with the web UI and configure SSO to authenticate to your Active Directory domains and/or other sources as desired.

10) Manually reconnect to your ESXi hosts if you selected this option

11) Install Update Manager using a 32-bit DSN and the 2008 R2 Native SQL Client.

Now you’ve got vCenter 5.5 using your same database but on a clean Windows 2012 server.  Now you’re ready to take advantage of the new features ranging from the improved web interface, expanded OS support and the ability to update your hosts to ESXi 5.5.  Happy virtualizing!

mofr
Enthusiast
Enthusiast

you are right.

u can just install fresh vCenter and disconnect ESXi from existing VC and connect to new fresh one. new vCenter will detect all VMs from connected ESXi servers. no problem will be with it.

if you write down in more details what changes you have implement I will be able to say for sure.

---------------------------------------------------------- MCITP: Enterprise Messaging Administrator MCSE: Messaging VCP4 Blog: http://vforv.me/ Twitter: @sgaldava
Reply
0 Kudos
alex_g60
Contributor
Contributor

I thought I would share my experience going from 5.1 to 5.5 using the guide from above:

I tried doing an in-place upgrade of my 2008 R2 vCenter server (connected to seperate SQL 2012 VCDB database servers and no SSL Certs), and the SSO prerequisite check steps bombed out because apparently SSO doesn't sync passwords in "Linked-Mode".  Plus, the complex passwords I used in the SSO GUI, don't play nice behind the scenes if you have special characters in them.  (SSO accepts the password anyways I guess in 5.1).

So I followed the guide above, and all is well, until I find out that when you move the host into the new 5.5 vCenter server (using the existing VCDB database), the hosts can't synchronize their dvSwitches. (If someone can shed some light on why I haven't heard a peep about "Exporting your dvswitches via the web client", that would be great.)

Plus, VMware needs to overhaul their "Alert Management" console window.  It's a very painful experience when you have to re-configure rules, with no ability to export, import, backup, restore, etc.  (There's no official way to copy alerts among vCenter servers???)

Besides those two items, it worked out pretty well.  Thanks for the guidance, and I hope SSO goes better from here on out.

Reply
0 Kudos
rb51
Enthusiast
Enthusiast

hi

I do not want to hijack this thread, but...

I have used the instructions and it seems to have worked fine.

Just on question:

How do we sort out certificates? I can login via web client with no problems but the warning "the identity of this website has not been verified"; "Server's certificate is not trusted" still appears.

I am trying to find out more info on this.

Reply
0 Kudos
WaynardS
Contributor
Contributor

So I can use a database associated with a 5.1 vcenter when installing vcenter 5.5?  What I mean is do i have to upgrade to 5.5 before moving to a new host or can I just transfer my current database to my new server? 

Reply
0 Kudos
bleibold
Contributor
Contributor

I have the same question as WaynardS, except I have a 5.0 vCenter server/database that I want to move to a new VM.  I would like to change the OS (currently 2008, move to 2012 R2) and SQL (currently SQL 2008, move to SQL 2012 R2).  We are using a distributed switch, which complicates things as well.  So the question is, can I just build the new VM/SQL server, backup the 5.0 DB and move it to the new machine, restore it in the new version of SQL and install 5.5 pointing to that DB and all will work (assuming I brought over the SSL certs and kept the same name/IP address for the vCenter server)?  If I don't move the ADAM database, is it just security permissions that are lost or do lose anything else?  Isn't licensing info in there as well?

Thanks,

Bob

Reply
0 Kudos
WaynardS
Contributor
Contributor

Bleibold,

I contacted VMware for help regarding my question and the tech said that you can move the database and then install the latest VMware.  A couple of things to note, he said that I needed to install the same sql native client for the dsn that will be on the new machines sql server.  So we are going from sql 2005, with a native client of 9, to sql 2008 with a native client of 10.  I will install native client 10 on the old box before I move the DB to the new server.  Also after you move the database you can change the dsn on the old box and point it towards the new server and vcenter should work fine.  This is a good check to make sure the database moved and there are no problems.  After that you can turn off that machine and install vcenter fresh.  The adam does have the security permissions but I did read that vcenter backs those up to a certain table and can restore them if necessary although I'm not sure if they would be restored by just moving the db?  Not sure about the licensing part either.

If your environment has view be sure to upgrade those components as well because they are not compatible with vcenter 5.5 if they are below version 5.2. 

Reply
0 Kudos
rb51
Enthusiast
Enthusiast

Waynards,

I have also open a ticket with support, as I cannot find docs on how to perform this OS+SQL version changes (Win2008R2 to Win2012R2 and SQL2008R2 to SQL2012).

Thanks for the tips on your previous post.

If I hear anything else from support I will update this thread.

Forgot to ask: Did you keep same hostname+IP address on you new vCentre???

Reply
0 Kudos
WaynardS
Contributor
Contributor

Yes we did so we could reuse the same certs. 

Reply
0 Kudos
bleibold
Contributor
Contributor

I opened a ticket with VMware as well.  Their response was that because we are using a distributed switch that we can move the DB, but we need to move the hosts back to standard switches first:

Question: We are using a distributed switch, will that cause any issues?

Answer: This is an extremely important step ,as  is vCenter feature and the new vcenter that you are going to install would not have dvSwitch configuration at all .  Hence when you connect to the old database which has the dvSwitch configuration ,the might be issues with regards to connection with the hosts.  We have to migrate the hosts networking back to Standard Switch and then install the new vcenter ,creating the dvSwitch configuration and migrating accordingly."

So, VMware seems to indicate that the distributed switch might not work correctly by just moving the DB and installing 5.5 fresh.  And it seems Alex_G60 above experienced something along those lines "the hosts can't synchronize their dvSwitches".

Not sure where that leaves me.  VMware is saying it can't be done w/o moving to standard switches first and I am leery to try it without their blessing.  If I have to move the hosts back to standard switches, I don't see much reason to even move the DB.  I only have one cluster and 11 hosts, so it wouldn't take much to just recreate and disconnect from the old vCenter and connect to the new once the hosts are on standard switches.

Thoughts?

Thanks,

Bob

nicbur
Contributor
Contributor

Hi,

Any news regarding dvswitch and export/import from win/sql 2008 vCenter5.0 to 5.5 with sql and os in ver 2012 r2, is it possible or do I need to change to standard-switch?

br

Nick

Reply
0 Kudos
bleibold
Contributor
Contributor

Hey Nick,

I will know for sure by the end of this week.  Our production vCenter upgrade is scheduled for this Thursday night.  I have upgraded our test environment in this fashion (install new Windows 2012 R2 server with SQL 2012 SP1 and restored the DB).  I have also setup a test environment with a similar setup to my production environment and have been doing some testing there.  So far, all my tests have been positive, the distributed switch seems to come over just fine with the database restore.  In addition to the database, you need to grab the SSL certs from the original vCenter (see kb.vmware.com/kb/1014314 for details).  Not specific to the database move, but also ran into this issue with the web client (kb.vmware.com/kb/2044953).  If you're running vCOPs, the move will give it some problems (kb.vmware.com/kb/2047351).

I had also opened a ticket with VMware and they confirmed this process should work.  If your ESXi host management interfaces are on the distributed switch, they recommend moving those to standard switches, but most folks have them on standard switches already (as we did) so usually not an issue.

I'll try to remember to update this thread after the upgrade later this week.

Bob

Reply
0 Kudos
rb51
Enthusiast
Enthusiast

Hi Bob,

When restoring the VCDB to the SQL2012; do you do within SQL on 2008R2 compatibility mode or SQL2012 native mode?

On my test environment (mirror of Prod but with only 2x hosts), I setup the Win2012 VM with the bios hack and SQL 2012...However it didnt work well, with lots of service failures, etc.....Because we are kind of rushing against time. I will be sticking to Win2008R2 and SQL VMs for the time being.

Ric

Reply
0 Kudos
bleibold
Contributor
Contributor

Hey Ric,

When I restored the database, it automatically set the Compatibility level to "SQL Server 2008 (100)" on the restored DB.  I left it at that.  Not sure I will come back at some point later and try to update that to SQL Server 2012 (110) or not.  Trying to change as little as possible during the upgrade and don't see a big benefit to upgrading the compatibility level at this point.

I didn't see any service failures after the install.  Had to set a couple of services to run under the same account as the vCenter service was running under for them to work, but that was it.

Bob

Reply
0 Kudos
nicbur
Contributor
Contributor

Hi Bob,

Thank you for this nice reply, exactly what I needed! Smiley Happy

This is only leaving me with one question so far.

My management interface is on a vDS, why are they recommending to change it to vSS?

Best regards

Nick

Reply
0 Kudos
bleibold
Contributor
Contributor

Hey Nick,

That's a good question, we never went into detail on it as our management interfaces are on standard switches.  In a past job we always put them on the vDS too.  This is an environment I have inherited and they were on vSS here so have just left them there.

His exact comments were:

"Since you have the management network on vSS(Standard Switch) and the vCenter being a physical machine . You do not need to move the VMs which are on the vDS to vSS provided you use the same vCenter database."


I am guessing it's more just a safety thing than anything.  In case the vDS goes belly up in the move, you can still get at your hosts directly and the vCenter box to right the ship.  I don't see why it wouldn't work with the management interfaces on the vDS, but might be missing something.


Bob

Reply
0 Kudos
RaymondG
Enthusiast
Enthusiast

Hey, I've gone to new versions of esx about 2-3 times starting from 3.5 to 4 etc........each time I started fresh.....But this was because I was usually going from old hardware to new (as vcenter wasn't recommended on VM previously).  I also thought it was safer......I could completed screw up the install and not harm production.    I've never had any issues with a fresh start.....but I also created a new DB(table only, not server).  So I essentially had two running environments at the same time, when done.  At this point, you can just transfer servers over by disconnecting from one and reconnecting to the next.

I've never have any trouble with vss or vDs.   You just have to make sure the spelling and the Case is exactly the same on each, and everything should work find.

I now have 5.1 on VM and was thinking of trying to upgrade this time instead of going fresh to 5.5, which Is how I found this thread......  you are making me think twice though.   I just felt the fresh start would be a little more in involved with the additions of sso etc..     How did you make out?  did you continue with the upgrade? or start fresh?

Raymond Golden VCP3, VCP4, MCSA, A+, Net+, SEC+
Reply
0 Kudos