My last 6.0 patch upgrade had an interesting phenomenon. Staging of three of the patches worked without a hitch. Before I could install the next patch, however, I had to cold-reboot the nodes. A soft reboot caused a red message to the console complaining about a module that would not load: a module I did not recognize, and now cannot remember. However, when this happened I did a cold reboot, and everything looks like it worked.
Recently I added some hardware, and once I did, my vSphere hosts were no longer within the profile; neither were they at the latest patch level. I would have expected little to change within the host profile, but once you add hardware, things change in the host. The same thing happens during every update in which either new features are added or bug fixes are made to the subsystems a host profile cares about. Continue reading vSphere Upgrade Saga: Maintaining Host Profiles After Hardware and Software Upgrades
In my past upgrade sagas, I had upgraded vCenter and then fixed a few niggling problems (or attempted to). Now it is time to actually upgrade the vSphere servers. I previously staged the vSphere 5.5 ISO into the VMware Upgrade Manager (VUM). Since all nodes need to be rebooted to do the upgrades, it is also a good time to update firmware. Otherwise, the upgrade is pretty straightforward. Hopefully, it will fix my remaining issues. Continue reading vSphere Upgrade Saga: Upgrading Blades to vSphere 5.5
This is the week end I move all my existing hosts to vSphere 5, to make way for some other work. Actually, I will migrate 2 of 3 hosts, while leaving one host at vSphere 4, more later on why. While Host Profiles has greatly improved, it is still not sufficient when updating and migrating nodes that use physical virtual NIC devices such as HP Flex-10. Why? Because they want to know the MAC Address when you apply the profile. This is a chicken and the egg sort of approach to Host Profiles. Continue reading vSphere Upgrade Saga: Migrating Existing Hosts to vSphere 5, Host Profiles not Enough!
The other day, yesterday to be exact, I completed a long standing task of my vSphere Upgrade. Migrate my vCenter Server database from the vCenter Server to a dedicated MSSQL Server. I have always wanted to do this, but licensing and other issues always got in the way. There were three reasons for this change:
- I needed a MSSQL server for other tools such as HP Insight Dynamics
- I have been installing Application Performance Management Tools and it would be very cool to see how vCenter behaves in a dynamic environment
- I have a need to add more hosts and therefore more VMs. So needed the space to grow.
The steps are remarkably simple, if your MSSQL databases are the same version, which mine are as I went through the upgrade process from MSSQL 2000 at the beginning of this migration. These steps are:
- Use the Microsoft SQL Server 2008 Import and Export Data (64-bit) tool to migrate your data from one MSSQL Server to another. Be sure you create new databases on the target MSSQL server and move both your vCenter and VMware Update Manager (VUM) databases.
- Update the 64-bit DSN for vCenter and the 32-bit DSN for VUM
- Follow VMware KB article #1003928 to update the username and password used by vCenter to access the database
- Follow VMware KB article #1015223 to update the username and password used by VUM to access the database
After all that was completed, vCenter connected and worked just fine. I had no data loss, which is what I wanted. But VUM did not work. I received ‘Failed to Load’ errors when looking at the VUM screens. A search of VMware’s KB articles and VMTN stated I needed to upgrade to VUM version 4.1 Update1, which I did. The problem persisted. All in all not a very good way to end the day.
So I asked myself, is the VUM data all that important to me? In some ways it is, but in many it is just not that important, the same information is already on each ESX host (when updates occurred). So with this realization, I reinstalled VUM and choose to use a Fresh Database. Viola, VUM started working again. So apparently VUM encodes something into the database which caused this failure, but since the update data is retrievable from VMware, using the old database was not all that important to me.
For those who use VUM to upgrade VMs or have lots of hosts, VUMs database may be important to you but since I only use VUM for hosts and not VMs and I had other means to find the same data, it was not a huge issue. My major issue was preserving my vCenter database, which this method of migration did admirably.
So now do I remove MSSQL 2008 from my vCenter server or leave it. I choose to leave it as vCenter requires the SQL Native Client 10.0 and there is a chance if I remove all of MSSQL 2008, the client will also be removed as it is not a normal part of Windows 2008-R2 but I did remove the old data.
Thanks to Cody Bunch of the twittersphere helped me to solve the latest mystery within my vSphere environment: vCenter would fail to start after a reboot of the Windows 2008 vCenter Server VM. This has been plaguing me since I started this process, but it finally needed to be fixed!
The problem is that VMware Update Manager and VMware vCenter Server collide when they are both trying to access the MSSQL 2008 database for some odd reason.
The solution is fairly easy, add a service dependency on VMware Update Manager so that it requires VMware vCenter to start first. To do this open up regedit and navigate to HKLMSystemControlSet001servicesvmware-ufad-vci key and add a new Multi String Value named ‘DependOnService’. Give this new registry element a value of ‘vpxd’.
This will now place a dependency on VUM such that it requires vCenter to start first. Now on reboots, vCenter starts properly and I no longer have to manually start the service.