This is related to the "status" display function being broken with the VC 2.02 Update 2 level. When I reviewed the Release Notes, I did not make the link between the GUI Status lights and the PERL Scripting used by our teams so we had breakage in these important PERL automation scripts. After contacting VMware support, they conveyed that there is no solution yet and they consider this a "cosmetic" issue but I disagree as this NOT in this case as we do have clear breakage of our automation scripts. VMware provided a basic workaround and that is to select an entry at the highest level in the VC "inventory" tree and then edit one of the alarms, change a trigger value to something else, trigger the alarm, let it apply, then change the value back, then the status will be updated. However, there is a problem with that solution. As soon as a VM is shutdown, the status reverts to "unknown" and will not be restored properly with the next power on, therefore the status is broken again.
As a more robust work around, I implemented an alarm which will trigger each time a VM is powered on which will then update the status so it is correctly reflected in the GUI as well as for the Perl Scripts and it will retrigger each time from shutdowns as well. I investigate various other alarms such as CPU, Memory and Heartbeat (there are known problems there too) but I was not clever enough to coax it to work consistently using those as the problem resurfaced during the shutdown cycle. The only side-effect we've see thus far is that powered OFF VMs, the one's least likely impacted, will show the "warning !" icon on the VM. I've not determined as way to make the status update work w/o the icons but if you can live with this, it will keep the status of the running VMs correct, even after a reboot and you do not have to mess w/ Cron jobs or restarting other ESX jobs.. and it let's the automation scripts work properly.
Steps..
On the General tab, create an alarm called "Force Status to Work" with these settings --> Monitor the VM, Red, Enable
On the Triggers tab, Select Trigger Type --> Virtual Machine State, Condition --> Is Equal To, Warning --> Powered Off, Alert --> None
On the Reporting tab, leave the values at 0
On the Actions tab, select no actions.
Does anyone know how to improve this temp workaround further? I've also asked VMware to escalate this problem beyond a "cosmetic" issue.
Later,
GC Mobley, IBM Tivoli
Later,
GC Mobley
