VMware Cloud Community
kurtdepauw
Contributor
Contributor

Virtual Machines status not correct vissible

Hello,

We have at the office 3 ESX servers, after upgrading to the new version of VirtualCenter 2.0.2 I can see that only on one of our ESX server nodes the status is correct visuable

see screenshot

http://www.fekanv.be/vmware.jpg

Regards,

Kurt

Reply
0 Kudos
43 Replies
bjmoore
Enthusiast
Enthusiast

Looks like you're right. After I restarted the VirtualCenter service the status lights disappeared again. I'm on fully supported hardware. Mostly I've been back and forward with support. It seems like they're still trying to get a handle on a lot of the new 2.0.2 bugs. At least this one's not major.

Reply
0 Kudos
marvinthebassma
Contributor
Contributor

That's not nice !

We have an ELA Platinum.

I will create a SR next monday because I spend today much time in restarting the agents and I can imagine that restarting the VCenter service would end up in loosing all status information.

Our HW is HP Proliant DL 385 G1 / G2 DL 585 HDS San ...

Reply
0 Kudos
sbeaver
Leadership
Leadership

I am seeing the same thing also running on HP hardware

Steve Beaver
VMware Communities User Moderator
VMware vExpert 2009 - 2020
VMware NSX vExpert - 2019 - 2020
====
Co-Author of "VMware ESX Essentials in the Virtual Data Center"
(ISBN:1420070274) from Auerbach
Come check out my blog: [www.virtualizationpractice.com/blog|http://www.virtualizationpractice.com/blog/]
Come follow me on twitter http://www.twitter.com/sbeaver

**The Cloud is a journey, not a project.**
Reply
0 Kudos
joelgb
Contributor
Contributor

Thank You everyone!

I'm glad my trials are reproducible on supported hardware. For us at least this problem showed up sometime after a 2.0.1 patch back in early June.

Heres what I have gathered so far:

It seems to me that some of the alarms are not working properly and/or are not correctly refreshing the status lights correctly. If you remove all virtual machine alarms, your status lights will never change and will always be white (by design I believe).

Some of the alarms appear to not be changing the status color initially to green. This idea is confirmed as I have noticed that a status light will change if an alarm is triggered (maybe a CPU alarm changing from white to yellow or red, and then will return back to green). From that time on, that VM's status light appears to be working fine. The alarms not initially changing the status light are: VM CPU, VM Mem, VM Disk, VM Network

I then found that If I added either one of the following two alarms, Virtual Machine State or Virtual Machine Heartbeat, the status lights would initially turn green. The status lights continue to stay green even after restarting the Virtual Center Service, no restart of vmware-vpxa on the hosts is required.

So for right now I have added the Virtual Machine Heartbeat monitor, also thinking that maybe the status lights not working are the Virtual Center service missing some heartbeats. The only oddity I am seeing is that powered-off on virtual machines have a status of green. As it was explained to me, powered-off VMs should not display a status light... I haven't had too much time to work on that issue.

Additionally I tried setting the VM State alarm up (set yellow and red triggers to none) and this alarm also makes all status lights turn green.

Reply
0 Kudos
hazent
Contributor
Contributor

I've also noticed after upgrading to VC 2.0.2 the alarm actions are not working. Even after restarting VMware-vpxa and mgmt-vmware. I was able to resolve this by disabling the alarm, then re-enabling it.

Reply
0 Kudos
meistermn
Expert
Expert

I am having the same problem with HP 585 G1 /G2 and Fuijtsu Server RX600 S1 .

Reply
0 Kudos
bsm033
Contributor
Contributor

I have the same issue

I think its because the VC and the ESX rebuild version is not the same

VC = 2.0.2 50618

ESX's = 3.0.2 52542

I have been opened support ticket to that no resolved yet

The lust time its work for me when the VC and ESX's rebuild was the same

VC = 2.0.0 27704

ESX = 3.0.0 27701

Maybe in 3.1.0...

Reply
0 Kudos
Rod2
Contributor
Contributor

Current fix from support is to run the service restart options for mgmt and vpxa; this does not work for very long however. You will find that after a day the status begins to disappear from the VMs.

Reply
0 Kudos
masaki
Virtuoso
Virtuoso

Don't care about the build number.

the version is important (ESX 3.0.2 and VC 2.0.2)

Reply
0 Kudos
jeremypage
Enthusiast
Enthusiast

I am also seeing this issue, 2.0.2 with 3.01 and 3.02 mixed.

All VMware certified IBM gear.

Reply
0 Kudos
falk_
Contributor
Contributor

I also see this issue.

2.02 and 3.02 on HP DL585.

Is it ok to:

service vmware-vpxa stop

service mgmt-vmware restart

service vmware vpxa start

on a production system?

I read that the vm's could restart if you did a restart on mgmt-vmware on a non patched system?

--

Regards Falk

Sweden

Reply
0 Kudos
Bill_Morton
Contributor
Contributor

I can also see this issue, certified hardware: 2.02 & 3.02 HP DL385 w/ QL4050

It seems that after the 2.02/3.02 upgrade my alarms don't work anymore. I can get them to turn "green" if I add a heart-beat alarm to the VM, however they don't trigger anymore (turn orange or red) for memory or CPU. Only the HB will produce an alarm.

I may remove every alarm and re-create. That and start a ticket with VMW so they know this is a widespread problem.

Reply
0 Kudos
Ercole77
Contributor
Contributor

I also have this problem, very heavy!!!!

3 ESX 3.0.2 (IBM 3650) (DS4800 SAN)

1 VC 2.0.2

What's the solution?

Reply
0 Kudos
Bill_Morton
Contributor
Contributor

The solution is to edit every alarm, and change the values for warn and alarm to something new and apply. Then edit the alarms and change the values back. Aparently the values get truncated during the upgrade and have to be re-created before they are actually set post upgrade.

All of my alarms are now working after editing.

Reply
0 Kudos
Ercole77
Contributor
Contributor

Thanks Bill!

i'll try tomorrow

Reply
0 Kudos
hazent
Contributor
Contributor

Bill,

Editing all of the alarms changing yellow and red values; save; and change back to original values resolved my issues with the alarms as well.

Thanks for the good work,

Todd

Reply
0 Kudos
virtualray
Contributor
Contributor

Bill's method worked for me however, when i add new virtual machines the recently added vms do not show alarm status without changing the alarm settings again. I sure hope a fix comes out soon, i would hate to do this every time a server is added. But kudos to Bill for the workaround..

Reply
0 Kudos
MBrownHenn
Contributor
Contributor

I have attempted all the suggested "fixes" with no success. It only works for a few hours or days and then they go back to either false positive green lights or no lights. I'm running ESX 3.0.2 and VC 2.0.2 with all the latest patches up to Oct 10th 2007. All hardware is HP DL585 G2's and a certified IBM SAN. It must be a problem with the SQL 2000 database and how VC accesses the data for alarms.

Is VMware watching? If so, fix this and release a patch for VC 2.0.2! You should be embarrassed.

Reply
0 Kudos
plusque
Contributor
Contributor

we have the same problem.

in our case there are two esx hosts 3.0.2 fully patched. guests are rheles4 - 5 and win2k3 (47vm's).

normally the problem occures after suspending the machines for snapshot. after resume no status is displayed.

"service vmware-vpxa restart" or "service mgmt-vmware restart" does the job,

does anyone put this into cronjobs? because in our case the problem occures every day!

have fun

Reply
0 Kudos
MrGEyes
Contributor
Contributor

I have had exactly the same problem with 2 x IBM x3850 hosts.

I have tried editing the alarms which made no difference and "service mgmt-vmware restart" which did resolve the issue temporarily.

I would also say that it is very intermittant and is liable to sort itself out for no apparent reason.

I noticed that when I removed a LUN that I was no longer using from the Datastores, all of a sudden the alarms kicked in and everything was okay. This was only temporary though and it went west again fairly soon after.

Reply
0 Kudos