Its now out. Applied it this afternoon. A couple notes:
When it comes back online, it will attempt to upgrade the vpx agents on all your hosts. I found that several upgrade attempts failed, a couple recovered. One host did not, remaining in a disconnected state.
Had to apply the vpxagent upgrade manually for that host's VC connectivity to be restored:
\- copy Program Files\VMware\VMware VirtualCenter 2.0\upgrade\vpx-upgrade-esx-6-linux-40644 to your host
\- run 'sh vpx-upgrade-esx-6-linux-40644' at the console, followed by 'service mgmt-vmware restart'
\- in VC, right-click host, Connect
Another note:
HA gets reconfigured on all the hosts. Same with DRS. We found that DRS started moving things all around (we have it automated), so the upgrade process will potentially generate significant load on your hosts.
HA reconfiguration failed on a few hosts. Removing HA from the cluster, then re-enabling it restored HA.
You may want to consider disabling HA & DRS on your clusters before upgrading Virtual Center.[/b]
Regards,
J
Message was edited by:
hicksj
Great recommendations. I have one modification: disable HA, but not DRS. disabling DRS requires that you rebuild all your resource pools which for us would be a pain. I went through the upgrade by disabling HA only with no problems other than long delays getting the hosts to reconnect. Forget about doing this during business hours.
After upgrading VC:
On ESX Host:
service mgmt-vmware restart
service vmware-vmkauthd restart
service vpxa restart
On VirtualCenter Server:
Restart the VC services on VC server
Restart VC Licensing services on VC server.
Reconnect ESX hosts to VC
Is it just me or does Patch 2 create more problems than provide fixes? Reading this post and my own experiences with the HA clusters going crazy have prompted me to reinstall VC from the original 2.0.1 disc. I was not having these issues prior to upgrading.
Can someone explain what
service vmware-vmkauthd restart
and
service vpxa restart
do.
I believe that the mgmt-vmware restart command forces the Vi Client to refresh itself of any host specific changes (correct?) but would like to know what the other 2 do.
In all my searching prior to deploying VC Patch 2 I
have not read about the Patch level of the ESX hosts?
I am planning on applying all ESX 3.0.1 patches to
build 39823 and then installing patch 2 on VC.
Does anyone think this has an impact on the success
of the VC Patch 2 install?
Mike
I would suggest you evaluate each patch individually. Many patches are intended to address individual hardware requirements and may not be relevant to your environment.
eg. of the hotfixes (patches) available for esx3.01 we have installed 3, 2 of which were debatable as they are relevant to our environment but we have not yet experienced the issues which the patch addresses.
Well folks...after having the customized SQL jobs
running I removed them as part of the VC2 patch.
Guess what just crashed on my today after a few
months of working VC and only weeks after the patch
Check database connectivity before restarting. Error:
Error\[VdbODBCError] (-1) "ODBC error: (08S01) -
\[Microsoft]\[ODBC SQL Server Driver]Communication link
failure" is returned when executing SQL statement
"UPDATE VPX_ENTITY SET NAME = ? , TYPE_ID = ? ,
PARENT_ID = ? WHERE ID = ?".
Jesus, Joseph and Mary...
I have had this issue a few times since applying patch2, I opened an SR and was told its probably a database or network issue as there are no known issues with Patch2 (ya right). I have also seen the VirtualCenter Server service stop and fail to restart several times without any ODBC errors.
Did you also open a SR for this problem?
After applyng patch2 I'm seeing something similar in Oracle 9.2.0.1.0:
Il receive this error in application log
Error: Error\[VdbODBCError] (-1) "ODBC error: (HY000) - \[Oracle]\[ODBC]\[Ora]ORA-01461: can bind a LONG value only for insert into a LONG column
" is returned when executing SQL statement "UPDATE VPX_HOST SET DATACENTER_ID = ? , DNS_NAME = ? , IP_ADDRESS = ? , USER_NAME = ? , PASSWORD = ? , PORT = ? , ENABLED = ? , VPXA_ID = ? , MASTER_GEN = ? , MASTER_SPEC_GEN = ? , VMOTION_ENABLED = ? WHERE ID = ?
ù
Then VC service shuts down.
Any hint?
We also had this error back when we used Oracle 9.2.x. Our solution was to move to 10g since reinstallation of VC needs to rebuild the database anyway.
Unfortunately, I believe that the Oracle implementation of VC is not up to par, and in this case, I believe there is a stored procedure that is calling a value where it is different in Oracle than in SQL.
For this reason we are moving back to SQL2005. The community will help find the solution or fix before the VMWare team will admit that the Oracle implementation is not perfect.
We've been using Oracle 9.2 with VirtualCenter without any problems at all. Even through all the upgrades of VC.
I'm surprised.
You have upgraded from VC 1.1 -> 1.2 -> 1.3 -> 2.0 -> 2.0.1 and never lost performance data or overwhelmed your logging?
You must have an impeccable DBA on staff to help you through that series of upgrades. Kudos to your team.
Our history has not been so favorable, but our DBA staff may not have "the gift"
We do have great, very experienced DBA's, I've only upgraded from 2.0>2.01>Patch1-->Patch2 though.
I had to restart sshd on one server. 5 others had the typical mgmt-vmware restart problem. The remaining 7 worked fine.
we did this successfully ;
we had 5 hosts which need the agent installing manually ; not bad out of 35 hosts in total
just remember NO to overwrite the database. evil.
VCC upgraded perfectly, and 7 out of 8 agents upgraded. 1 required restarting the management service.
Are there any certain ESX 3.01 patches that are recommended in combination with VCC Patch 2? Obviously most of the ESX patches are 'as needed', but curious if there were any recommendations for the optimal combination.
Any luck with the error:
Error: Error\[VdbODBCError] (-1) "ODBC error: (HY000) - \[Oracle]\[ODBC]\[Ora]ORA-01461: can bind a LONG value only for insert into a LONG column
" is returned when executing SQL statement "UPDATE VPX_HOST SET DATACENTER_ID = ? , DNS_NAME = ? , IP_ADDRESS = ? , USER_NAME = ? , PASSWORD = ? , PORT = ? , ENABLED = ? , VPXA_ID = ? , MASTER_GEN = ? , MASTER_SPEC_GEN = ? , VMOTION_ENABLED = ? WHERE ID = ?
This is something that we also get from time to time with VC 2.0.1 Patch2. No solutions have presented themselves as of yet. Connectivity between the Oracle DB and VC2 servers seem to be OK - that system running oracle seems to handle lots of other application DB's just fine. Only VC2 has an issue. Our DB team hasn't been able to identify anything on their side as of yet.
I had one ESX 3.0.1 host that wouldn't upgrade the VC agent. Tried manual install which failed. Tried all the tips in this thread but with no luck. Eventually rebooted the ESX host and restarted the license service then readded host to VC. That did work.
VC is much quicker to respond!
Cheers
Paul
hello,
we had the tempdb problem and upgrade to 2.0.1 patch2. now we have the following issue:
\[2007-07-23 15:56:01.029 'App' 1196 error] An unrecoverable problem has occurred, stopping the VMware VirtualCenter service. Check database connectivity before restarting. Error: Error\[VdbODBCError] (-1) "ODBC error: (40001) - \[Microsoft]\[ODBC SQL Server Driver]\[SQL Server]Transaction (Process ID 52) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction." is returned when executing SQL statement "UPDATE VPX_ENTITY SET NAME = ? , TYPE_ID = ? , PARENT_ID = ? WHERE ID = ?"
as others also have this issue - any solution until now?
brgds Deas
To wilson94t
The solution to your problem could be to install Oracle ODBC drivers 9.2.0.8.0. Please see http://www.oracle.com/technology/software/tech/windows/odbc/index.html for the files and realese note.
SOFTWARE REQUIRED:
Microsoft Windows XP, Windows Server 2003, Windows 2000, Windows NT 4.0 or Windows 98 operating system.
Oracle Net Client 9.2.0.1.0
Oracle Universal Installer shipping with Oracle 9.2.0.5 patchset or 10g
I have the same problem and working on getting hold of "Oracle 9.2.0.5 patchset" /Marten