Day one could have gone better. You know you’re in a little trouble when Step 1 causes a significant delay in what was a well-thought-out plan. Anyway, the “enterprise” consists of:
-18 ESXi 5.0 Hosts (HP Proliant BL490c Gen 6 blade servers in two HP c7000 enclosures running HP Flex 10 network fabric). Seven of those hosts are in Development/Quality Assurance (QA); the other eleven are in production
-1 Brocade Fiber Channel SAN connected to a 60TB Dell Compellent holding all the datastores
-1 Physical vCenter Server
-237 Virtual Machines, of which 125 are in production
In preparation for the worst, I backed up the remote vCenter SQL database and ran a P2V of the physical vCenter.
The goal was, at then end of the day, to have vCenter upgraded. I planned on executing the Simple Install option because our environment is still considered small (under 100 hosts and 1000 VMs), and I’m putting all the modules on the vCenter server.
Step 1 is the new Single Sign On (SSO) service. It wants its own database created remotely or on the local vCenter server. Since we had the vCenter database on a remote physical SQL box, and my boss told me to, I decided to put it on the same SQL server. You can create the database manually or through the provided script in the 5.1 installation folder.
Our DBA created the database, and I was on my way… for a few seconds. The SSO asks for all the pertinent information: the type of database, the name of the database and hosting server, the TCP port, and a couple logins to access the database and write to it. There is also a field for the JDBC URL, but you won’t need it unless it’s an Oracle database. After entering all the information, I couldn’t connect to the SSO database. VMware user forums presented the following:
– – VMware 5.1 doesn’t support remote SQL databases
– VMware 5.1 doesn’t support remote databases in SQL named instances, which is almost impossible for enterprises with SQL servers to adhere to
– You must create a SQL login to the databases with the dbo role with SQL Authentication only because VMware 5.1 doesn’t support Windows Authentication to the database
I can tell you from my experience that the above isn’t true. Although I did create a separate login to the database, my stopper was the DBA had used port 14333 for SQL instead of the standard 1433. Once the port was correct, the SSO installer connected immediately. Duh.
Check with your DBA or confirm the SQL ports through the SQL Network Configuration tool before you start reading through forums for 45 minutes. That’s a pisser, right?
The rest of the installation went smooth. SSO, the Inventory Service, Web Client and vCenter all upgraded without a hitch. The next and last install of the day would be the VMware Update Manager. I will use the VUM to update the hosts.
Version 5 of VUM lives on the vCenter server, so I was more than a little frustrated when the installer for 5.1 couldn’t connect to the vCenter server even though it was the same server I was running the installer from. What? The FQDN didn’t work, neither did the IP address. I even tried (thanks to the forums) creating an alternate DNS entry for the vCenter server that didn’t have a certificate tied to it. Some had success with that strategy; I didn’t.
Finally, the VUM connected to vCenter using the loopback address. That’s right; there is no place like 127.0.0.1. The VUM downloaded the updates, and it finally looked like I could move on to the hosts.
The day was over, and the goal was met. Neat. Time for a drink; the hosts would still be there in the morning.