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?
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.
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?
November 03, 2013by KevinNo comments
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!
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).
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:
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:
For more information see the following KB article on certificate errors related to vCenter Server installation
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.
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.
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.
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.
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.
|1||Browse to Administration > Sign-On and Discovery > Configuration in the vSphere Web Client.|
|2||On 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.
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:
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!
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.
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.
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.
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?
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?
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.
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???
Yes we did so we could reuse the same certs.
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.
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?
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.
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.
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.
Thank you for this nice reply, exactly what I needed!
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?
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.
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?