For those of us who determined we were smart by not being so quick to upgrade to upgrade to ESX 3.5 Update 2 after the product expiration debacle, I should point out an important note so that you do not make the same mistake that I did. Given that VMware corrected the issue with the initial release of Update 2 (build 103908), I determined it was a good time to look at the new version in a test and development capacity. Today, I stood up two ESX 3.5 Update 2 host systems in my development cluster that are managed by the same VirtualCenter 2.5 Update 1 server that manages all clusters.
The build of the 3.5 Update 2 system was painless and indistinguishable from that of the previous releases, and it added into VirtualCenter just fine. The issue was that while I could add the ESX 3.5 Update 2 hosts into VirtualCenter, they were not listed as a compatible solution in the release notes compatibility matrix.
What is missing from the release notes is that by not compatible, VMware actually means “will break your VirtualCenter”. While yes, it is “not compatible,” my expectation was that it would either not permit the system to be added or it would not deliver the incremental functionality. The issue occured when I tried to restart the VirtualCenter service. Due to some scheduled database maintenance, I had planned to stop the service and restart it. The restart of the VirtualCenter (vpxd) service would not succeed, and I found this log file entry:
[2008-08-26 23:25:15.325 'App' 1872 error] [VpxdMain] Failed to initialize: not well-formed (invalid token)
The newer version of ESX within the VirtualCenter environment causes this issue. So, the following options were presented to this situation:
-Upgrade to VirtualCenter 2.5 Update 2
-Restore the database to a point in time recovery of before the addition of the two newer hosts (and shutdown the newer hosts)
If you are contemplating the Update 2 products, hopefully this gentle reminder to start with VirtualCenter will save you some surprises.