Tag Archives: SQL

Migrating vCenter to a new server

Maybe its during the upgrade from vSphere 4.0 to 4.1 and you require the 64 bit hardware. Maybe you need to upgrade to take advantages of a newer OS and you just don't trust the next next done that Microsoft provides you. Maybe its the fact that you currently have a physical vCenter and you want to take advantage of VMware High Availability and Distributed Resource Scheduler. Or maybe its the complete opposite and you are currently virtualized and you have your reasons to be physical. Whatever your reasons may be, there will more than likely be a time where you as a VI admin will want or have to migrate your vCenter to a new server. In my case, it was option number 4.

We had been running a virtualized vCenter ever since our upgrade to vSphere 4, however with the addition of the Distributed Virtual Switch, along with more and more third party applications depending on vCenter, coupled with a failure that left me unable to assign a vm to a network I just thought it was time to move our vCenter Server outside of the cluster that it was controlling. The decision to go physical was purely an overkill, but i wanted to have my vCenter completely disconnected from the san fabrics and interconnects that are currently the interworkings of our i/o flowing in and out of our hosts. I had read about the recommendation of management clusters, but the costs of building that would for sure outweigh the advantages of having it virtualized. Also, this will give us a central spot to house our PowerCli scripts and also run our UPS shutdown scripts from. So, physical it is, and here is my plan to get there. It wouldnt have been much of a concern but i wanted to have a solution where the dvSwitches would continue to function, and where i wouldnt need to go and touch every host afterwards. So, assigning this new physical vCenter the same name and same IP was a key step. Since i wanted to ensure a smooth transition i ran this one through the lab first using these steps. So here is what i had. vCenter1 (the current active vCenter) and vCenter2 (the new vCenter).

1. Get everything that you need (vCenter installation, 64 bit sql native client, sysprep files, etc). If vCenter1 is virtualized be sure to take note on which host its running on as you will need to disable or disconnect its network later on.
2. When you are ready to go stop the vCenter service on vCenter1.
3. Now we need to disconnect or disable the network on vCenter1.
4. Delete the current computer account for vCenter1 from active directory. I assume you could also just rename it, i just chose to delete the account.
5. Now lets move over to vCenter2 and do a few things. Rename this machine to vCentre1 and also give it the same ip as vCenter1. This should ensure that we don't have to ssh into each host after the upgrade and touch the hosts file.
6. Now just complete the installation of vCenter on vCenter2 which is the now vCenter1. (Confused yet?). Note – when asked about the database be sure to select to use the existing db, otherwise you can kiss all your hard work goodbye.

Thats all, you should be able to connect to your new vCenter instance using the same name or IP as you always have. You may have to reconnect your hosts however, as a new password for the vpxuser would have been generated with the new install and the hosts and vCenter will be out of sync. Thats as simple as right clicking your host, selecting connect and providing root credentials though. There you have it, a brand new vCenter! While your at it you might as well defragment your vCenter Server database as well to give it that snappy new feeling again. Also, there is a KB article which takes you through some of the steps above here. As always if you notice anything that I'm lacking or if I'm performing actions that will cause the market to crash please comment and let me know.

Giving vCenter a kick in the rearend!! – Defragmenting your vCenter Database

I've seen this happen numerous times on a number of our VMware vCenter installations.  For the first few months(sometimes days)  vCenter Server is very snappy and responsive, when moving from page to page things come up instantly and moving between different statistics and metrics on performance graphs is veryquick.  Then, as time goes by, things begin to drag down a bit, tabs start to take a little bit longer to load when moving between them, performance graphs can throw exceptions and things just generally slow down.

Of course there are many issues that could be causing this to happen, but the most common that I have found is a fairly simple one, a neglected VMware vCenter DB that is full of fragmentation and in need of a little TLC.  I don't want to go into what exactly database/index fragmentation is, but a good read if you have the time (and interest) is here.  Also, VMware has released KB Article 1003990 as well, which covers off fragmentation within the vCenter DB.

And then there is also my explanation….

When I'm looking at tuning my vCenter DB, the tables that I find myself always defragmenting are as follows..

VPX_HIST_STAT1
VPX_HIST_STAT2
VPX_HIST_STAT3
VPX_HIST_STAT4
VPX_TOPN_PAST_DAY
VPX_TOPN_PAST_WEEK
VPX_TOPN_PAST_MONTH
VPX_TOPN_PAST_YEAR

As you may guess, these tables hold historical and rolled up performance statistics and data.  Since vCenter is always  collecting data (depending of course on your Intervals and durations) these tables are constantly being updated (New stats coming in, old stats going out).  Just as in file level defragmentation, the large number of writes, updates, and deletes causes some tables to become heavily fragmented.

I'm not going to go through defragmenting all of these as it is the same steps for each table/index.  For this purpose I'll just go through VPX_HIST_STAT3.  First off, to see the fragmentation inside a table just run the following command in SQL Server Management Studio

USE [vcenter database name] GO
dbcc showcontig([tablename],[indexname])
GO

You can retrieve the names of the indexes either from  KB Article 1003990 or by expanding the Indexes folder in SSMS.  Essentially this command translates to..

Use VIM_VCDB
GO
dbcc showcontig ('VPX_HIST_STAT3','PK_VPX_HIST_STAT3')
GO

In my example this returns the following stats.

To summarize these results for a VI Admin, the lines that you should really be looking at is 'Scan Density' and 'Logical Scan Fragmentation'.  In short, you want Scan Density to be as close to 100% as possible, and Logical Scan Fragmentation to be as close to 0% as possible.  To defrag the indexes in this table we use the following command….

dbcc indexdefrag('[databasename]’,'[tablename]’,'[indexname]')

so, after filling in the values we get…

dbcc indexdefrag ('VIM_VCDB','VPX_HIST_STAT3','PK_VPX_HIST_STAT3')
 
which then returns….
 

As you can see we now have a lower Logical Scan Fragmentation and a higher Scan Density.  This is the expected result we want from the defragmentation.  Just repeat this step on all of the indexes and tables you want to defragment and you should be enjoying a much snappier, more responsive vCenter Server in no time.  Keep in mind, some smaller indexes and tables will always be fragmented and not much can be done to correct that issue.  Personally, I concentrate on the 8 tables listed above.  Keep these tables/indexes happy and you are well on your way….