Here's another update:
One of my hosts is showing a CPU usage alarm from 1am this morning. The alarm is set to trigger at 75% utilization. The host is now running at 40% but the alarm won't clear.
Also, when I try to export a performance .xls for this host, I get nothing but zeroes. I wonder if VC2.0.2 expects the hosts to be at the .0.2 level for some of these functions. My hosts are still at 3.0.1.
thanks it worked for me
Thanks guys, I had to change in /etc/hosts
The caps of the local host name in /etc/hosts was mad.
upgraded this morning, disbaled HA first. 2 out of 5 servers came right back up. Had to restart the agents on one and about 20 minutes later the other 2 reconnected.
The autrun would not launch had to start the installation from the /bin folder.
We have 2 clusters 1 amd 1 intel. The intel cluster can vmotion the amd cluster times out.
vpxd runs at 99% utilization cyclical 2.01 did as well. Vcenter servers is virtual.
For the past month or more virtual center has bee balky and slow to do things i/e edit settings on a guest
open console etc.
I'm shortly before my upgrade from VC 2.0.1 to 2.0.2. I read again the complete thread but its hard to figure out which combination will cause problems or if its better to wait for an hotfix if needed.
The HA, VM Status error - is it only with ESX 3.0.1 hosts or do some of you have the problem also with ESX 3.0.2.
So far its not clear for me if it can be fixed with service restart or upgrade to 3.0.2 permanently. And whats about ESX 2.5 hosts any problems with them so far?
Hi, We upgraded our VCS to 2.0.2. yesterday. We had al the trouble described above with the HA option. We edited the /etc/hosts file and everything was ok....exept the alarms.
There are none, not even from a reboot or 95% CPU utilisation.
We restarted the services with:
\# service mgmt-vmware restart
\# service vmware-vpxa restart
I'm very interrested to find out wether an upgrade to ESX 3.0.2. will solve the problem permanently
upgrade to 3.0.2 brought the sun back to my life. We had no more HA issues after that. But I'm still looking for them
Headless upgrade itself went through without any problems. You should do that. VMware support recommended it strongly to me.
Alarm issues are still present.
I will do that. esspecially since we want to implement VCB 1.0.3.
With regard tot the alarm issue, I noticed, that the vitual machine window does not refresh. For instance, server uptime remains unchanged " 23 minutes" ...untill I press F5, and refresh the window, the uptime will than change tot the actual time. wich than freezes........Is this a setting somewhere?
We can now vmotion from bith clusters after the upgrade.
I noticed that running vmkping on one of the hosts was not replying.
Another observation I noticed is now when I pull a patch cable from a nic under the vic
the nic now longer puts a red x on the nic under network configuration ( tested this on a couple of servers).
However I threw on esx server into I believe isolation mode when disconnectiong one of the console cables to it. All vm's showed as powered off could not start any vm on the host error message no swap space found.
At this point rebooted esx server vmkping started working. Powered up vm's on the other server created new uuid's for those hosts to get them running. Then started vmotions seeing that during the upgrade i changed drs to make recomendations.
No there's no setting. It works not as it is intended to be. I'm in contact with support but they could not reproduce this problem.
Please open up an SR everyone with this problem to show that I'm not the only one!
Two questions for those of you having the alarm problem:
1. Did you all start out with VirtualCenter 2.0.1 or earlier, then upgrade to 2.0.2?
2. What databases are you using with your VC installs?
Please send me a Private Message with this info if you can.
VMware Technical Support Engineer
I have a few questions as I plan on upgrading from v2.0.1 to v2.0.2
1. Currently we use ESX v3.0.1 + VC 2.0.1 + SQL 2005 SP2, the VC services stopped pretty often. Anyone know if there is any known issue with such configuration, or can confirm that VC 2.0.1 is Incompatible[/b] with SQL 2005 SP2?
2. If I prefer to create a brand new DB during upgrade (from v2.0.1 to v2.0.2), which one if better:
\- Remove VC 2.0.1, install VC 2.0.2 from scratch
\- Run upgrade, create new DB/DSN
I upgraded to VC 2.0.2 because a reinstall of the VC 2.0.1 was hanging up on a database issue so I could not start the VC service. Then after talking with VMware, they recommended the new VC version. I had an issue at first with the existing SQL database missing some items but since our VI3 infracture setup is new for us I did not mind creating a new SQL database that fixed that issue.
Another problem was our existing ESX servers running 3.0.1 that were not able to get the upgraded version of the VC agent. That error went away after a while by itself as the install from the VC server to the ESX host finally succeded.
After that it was an issue with licensing so I had to take our Single Host license files and delete them and combine them with our VC server license into a single file (from the VMware licensing site)
After that was done the ESX servers were pointed to our license server running on the VC server and it was ready for use.
I have been able to setup a datacenter and use cloning so far and it seems to be working well.
I got this from VMware Tech who talked about running SQL2005. It should work with the new version of VC 2.0.2. This is what he sent to me that may help. Do you know of any errors from the Windows server running the VC server? Check the Event logs to see what you find.
If the VirtualCenter Server service installs but does not start and logs the following error, this is a symptom that the SQL Server 2005 SP1 database is not configured correctly:
Failed to init tableDef: Column VER_ID does not exist in table VPX_VERSION. Database version may be incompatible.
This condition can occur if VirtualCenter Server was installed using a database login mapped to a user other than dbo. When the VirtualCenter login is the owner of the database, the login automatically maps to the dbo user. There are two ways to achieve the correct configuration:
Configure a fresh installation.
Repair a fresh installation that does not start.
To configure a fresh installation:
Connect to your SQL Server 2005 server with SQL Server Management Studio.
Create a database login (vclogin) for VirtualCenter Server to use.
Create a new database (VCDB) and change the owner from ', @map = 'true'
Start the VirtualCenter Server service.
thanks dwalker-isi, I also get that article, and realized that address the issue between v2.0.1 and SQL2k5 Sp1. In our environment we are using SP2. We had SQL ODBC types of error:
Check database connectivity before restarting. Error: Error\[VdbODBCError] (-1) "ODBC error: (01000) - \[Microsoft]\[ODBC SQL Server Driver]\[TCP/IP Sockets]ConnectionWrite (send())." is returned when executing SQL statement "UPDATE VPX_ENTITY SET NAME = ? , TYPE_ID = ? , PARENT_ID = ? WHERE ID = ?".
I am pursuing to remove v2.0.1, install v2.0.2 from scratch, recreate a new DB to resolve it.
If you know any hints that I should be aware going this approach, thanks to let me know.
I know the VC 2.02 release notes mention the importance of using the correct ODBC SQL driver?
I don't suppose that is your problem is it?
Note: The Microsoft SQL Server 2005 native client driver is not supported for installation or upgrade. You must use the SQL Server driver (not the native SQL or other drivers). If you are using Microsoft SQL Server 2005, verify that the ODBC driver configured for the database is the SQL Server driver. If not, you must reconfigure the SQL Server driver prior to attempting to upgrade or install this update. Otherwise, the installation will not succeed[/i]
Two questions for those of you having the alarm
1. Did you all start out with VirtualCenter 2.0.1 or
earlier, then upgrade to 2.0.2?
2. What databases are you using with your VC
Please send me a Private Message with this info if
VMware Technical Support Engineer
Please is there any updates?
Thanks dinny. I think we do not have problem comply with that. I verified that our ODBC is using Microsoft SQL Server ODBC Driver Version 03.86.3959.
I saw someone mentioned that ODBC drivers needs to update. I am not quite sure are they talking about newer version of MDAC or something else.
I will do a clean install of v2.0.1 using new DB so I expect the problem should go away.