Anyone upgraded to VC 2.0.2?

[peetz]

Hi,

since yesterday VirtualCenter 2.0.2 is available (s. Release Notes[/url]).

Anyone upgraded already? Any problems? Will the performance data and the custom attributes be preserved?

\- Andreas

[ttxn]

got the v2.0.2 installed on a new DB. was having problem unable to start VC service, install takes 10 min, troubleshoot took a few hours. Exact problem described at:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=656531...

VMware support provides very little help during the hours, even after I point out the right article to follow. The article confused me at :

3. Delete the database login that maps to it).

finally change owner to the DB, and got it fixed.

following problem exist after install

\- unable to allocate the templates we used to have

\- alert light stay green instead of red

\- don't know anyway to connect to old DB to find previous configuration.

add hosts / clusters / DRS/HA after install was fine

[Stewarts]

Ok, I wish I had read this before upgrading. I have problems no as I didnt disable HA before upgrading the VC server however the VC agent installed without an issue. I would just restart the VC service but I cant do that right now!

[Gabrie1]

Give this a try:

\- put host in maintenance mode

\- disconnect host

\- then de-install vc client and two HA components like this:

rpm -qa | grep vpx | xargs rpm -ev

rpm -qa | grep LGTOaamvm | xargs rpm -ev

rpm -qa | grep LGTOaama | xargs rpm -ev

\- reconnect host

\- exit maintenance mode

[Rynardts]

I got my VC to clear the alarm on my VM's.

We are using VirtualCenter 2.0.2.

The problem we had was that whenever an alarm triggereg on a VM (usually for CPU or Memory) the condition of the VM will recover, but the alarm would not clear.

What I did:

Where the Alarm is defined change the following.

Right click on the alarm definnition that wont clear -> Edit Settings

Click the reporting tab

Change the tolerance range to 1 percent above or below limit.

Let us know if it worked for you as well, or if I just got lucky

[pfuhli]

Hi there,

unfortunately I have to say that it didn't work for me. Alarms still remain at old status.

Regards,

daniel

[marvinb]

I opened a case about a very similar issue - here is the response i received:

Please follow these steps to reset the Alarms Reporting Tolerance:

1. Click on the host that has the alarm

2. Click Alarms - make a note of which alarm is still persistent (in your

case CPU usage)

3. Click Definitions

4. Select the field the CPU Usage alarm has for "Defines In" (e.g.

Datacenter) - click Datacenter

5. Right click the alarm - Edit settings

6. Select Reporting tab and set the value 0 for Tolerance and 180 for

Frequency (Lower the value if you wish)

The alarm should reset in 3 minutes.

another similar response from vm was:

This issue was noted before in another customers case and changing the values

even if it's the same values and saving it will fix the alarm. You can also

reset the VC agents on the ESX hosts by executing (service vmware-vpxa

restart). It appears to be a bug after doing the upgrade and the steps are a

work around from that previous case.

[Rynardts]

Strange,

It's been fine since I've changed that setting. Whenever alarms are triggered, they clear in good time.

Interesting... You must have some other issue then

[marvinb]

I forgot to mention that I had another exchange with the service engineer, and he said you didnt even have to change the settings, you just had to do another save.

Just once, I wish I could do an upgrade without all the "drama".

[smz]

Even if the alarms problem is cleared temporarily using this procedure or another, the main problem is not resolved and the alarms problem recurs very soon.

Any word from VMware on resolving this problem?

[NorbK]

Our upgrades were not without pitfalls but have all issues ironed out. First of all, not only was it bad to default the DB data to Master in previous releases, but then to basically say, "yeah, we are not going to support our default config anymore" and make you move the database manually was even worse. Hopefully the DB can stay put now!!

Out of 12 ESX servers only 1 had a HA failure and I did *not* uncheck HA in the clusters before upgrading VC. I don't think unchecking it would have helped anyway because the hosts entries and dns name was changed by VC to all caps for the servername. Why it had to do this to 1 out of the 14 who knows. I changed it back to lower case in the hosts file and under the DNS properties for the server in VC, rebooted the ESX server and HA was happy again.

I do have one other ESX host that after being upgraded to 3.0.2 doesn't seem to reconnect to VC after reboots. You can get to it via the VI client directly but it won't connect to VC unless I restart the management services. Its like they are not starting or not starting properly. I'll have to see where these are set to startup.

Otherwise, this was the first upgrade of ESX servers that I've done via Altiris. One job for the upgrade to 3.0.2 and another for the 15 post-3.0.2 patches. About 20 minutes for each job including the reboot for each. Everything went very smooth. As the farm expands further I can see this becoming a huge time saver!

[dougm]

I can say from experience, that the HOSTS name entries need to match the case that is in DNS.

I am at a client site and had to do an upgrade to an emergency upgrade to VC. Since I was not able to follow all the upgrade recommendations (long story) it broke a few things when I got it back online, HA being one of them. I found this entry in the VMware Community which led me to go look at the HOSTS files. The entries in the HOSTS were uppercase and DNS was lowercase. I edited the HOSTS entries and made them lowercase and all is now functioning correctly.