When I first took over our vSphere environment from one of my former admins who left the company, I was still getting my feet wet with VMware products. At that time I had very little experience with vSphere or VMware products in general. My background was Microsoft, some Cisco, having just obtained the CCNA, and SAN, and the virtual world experience was summed up in using Microsoft Type 2 hypervisor technologies.
I knew that I had to get a handle on our environment. Long story short, we actually started our journey with a couple of servers using Virtual Server. As you can imagine, not the most robust virtual environment. At that time, we were led to believe that we had a VMware skillset within our midst so on we went to rolling out VDI on 3.5. I can tell you it was painful to say the least. When the admin left, I was left with a few virtual servers running on a single machine running Virtual Server, while not tier one applications, still very important to the business, and a contract that was extremely unhappy with VDI performance.
After educating myself, building a lab etc, I conveyed to my management team that we needed to undo the mess that was made and do it right. At that time vSphere 4.1 had just came out and it was all the rave…and now I see why. We had very little time to get VDI out of the mess it was in and to start down our Server consolidation path. Yes, we certainly were late to the party, but my view is that we just needed to show up to start seeing the benefits.
Right away, I transitioned our VDI environment to View 4.5 and vSphere 4.1. I was still learning and still trying to retain all this information that was being thrown at me. Unfortunately, while we got the infrastructure, storage, and network right, I missed one very important thing and that was having a centralized DB MGMT tier to run our vSphere INF DB for things such as vCenter, VUM, View, etc. We were running SQL Express 2008 and after continuing to educate myself in reading the documents, obtaining certifications, etc, I realized that we were at risk not having a core DB for VMware Infrastructure Applications.
At that point a decision was made to create a centralized DB VM based on MS SQL Server 2008 R2.
Let me first start out by saying that I am not a DBA, however, after going through the process, it’s not that bad. Of course this process doesn’t take you deep into Database MGMT, etc, but you will learn some things along the way and today, I have no problem setting up SQL for vCenter, VUM..etc. It’s very easy as long as you make sure that you follow all the steps in the process and that you have some things figured out before diving in. As you know, installing SQL Express with the standard vCenter install is a cakewalk, but it could steer you down the wrong path, and one that you should really should not consider in a Production environment unless you are running less than 10 hosts and 50 VMs.
Since there is information freely out there pertaining the steps in doing this type of migration, I won’t reiterate it here. I’m not one for “reposting” whats been done or said by others. One particular site that has a step by step directions, broken down into 4 sections is here:
I first attempted this in my lab before I did this on our prod environment and my lab is a little quirky. On of the things I had setup in my lab was I had an account on my Domain that I was using for my “service” account for VMware Inf Apps, but it was the same as my actual Domain Name. My user account was CORE and my domain account was CORE. When you get to the reinstallation of vCenter, vCenter will autopopulate your account, except it will not include the Domain name in front of it. This did cause problems in vCenter 4.1 installation and users had to create a matching account locally on the vCenter server, install vCenter, then go back and change the service to start using the Domain service account. Back to my issue, however, I found that you can’t use an account that is:
1. The same name as your Domain Name, such in my case.
2. The same name as your vCenter Server Host name.
I hope this helps those that run into this issue. Use the directs from the blog I posted, but if you run into these particular issues, then make sure you remember these findings.
I also want to note that the vCenter 5 install has the same issues along with a requirement to have a Reverse Lookup Zone in your environment, which every Prod environment should have anyway. After the account is populated it does a reverse lookup on the FQDN of the vCenter server and if a Reverse Lookup Zone or PTR record doesn’t exist it will also fail the install.
Just some findings..hope this helps!