Rescan VMFS results in a deadlock of vCenter Server 4.x


When you’re using different types of storage in your vSphere environment, you might need to use different kind of alarms. So I thought to be smart and create a lot of folders and assign different alarms to these folders.  When the folders and alarms where ready, I moved the Datastores into the folders. Everything looks perfect so far. I was able to add different alarms for each type of Datastores. This scenario is also described by Jeremy Waldrop. The setup looks like this:

image

So far so good.

But… when I added a new Datastore and started a rescan on a cluster ……. vCenter freezes with a deadlock!

Continue reading

Advertisements

vSphere: False alarms on high VM Memory usage in vCenter 4.0


image

Since the upgrade to vCenter 4.0 and ESX 4.0 we got a lot of false alarms on VM memory usage. If you take a look in the advanced performance tab, at VM level. You’ll see that the VM is using all the assigned memory. When you take a look on the host OS, you’ll see that there is less memory usage then vCenter reports to you. I asked on Twitter if anyone else had seen this behavior before. @DuncanYB responded with a post, which he did earlier this year.  

So with the information from @DuncanYB I started a search at http://kb.vmware.com/ and found the following KB article: http://kb.vmware.com/kb/1014019. This article describes one of the symptoms that apply on our environment:

Summaries and Symptoms

Issues fixed in this patch (and their relevant symptoms, if applicable) include:

  • Fixes an issue where a guest operating system’s memory usage might be overestimated on Intel systems that support EPT technology or AMD systems that support RVI technology. This issue might cause the memory alarms in vCenter to go off spuriously even if the guest is not actively accessing a lot of memory.
  • Fixes an issue where DVFilter API’s fail for particular message types during message reordering.
  • Fixes an issue where DVfilter socket reads might fail if zero bytes are returned due to a connection close.
  • Fixes an issue with a DVFilter API where ESX might fail if a guest operating system is moved from one vswitch port to another. This fix allows dropping frames which are accidentally or maliciously posted to a different portset.
  • Fixes an issue where incorrect SysAlert() messages might be displayed on certain systems if the number of cache colors is not calculated correctly.
  • Fixes an issue with monitor or vmkernel crashing when running certain guest operating systems with a 32-bit monitor running in binary translation mode.
Deployment Considerations

BEFORE INSTALLING THIS PATCH: If you have set Mem.AllocGuestLargePage to 0 to workaround the high memory usage issue detailed in the Summaries and Symptoms section, undo the workaround by setting Mem.AllocGuestLargePage to 1.

I installed the patch on a Cluster whit this problem. After the installation of the patch mentioned in the KB article above, vCenter keeps sending false alarms. After a short search on the vmtn communities I found the following post of Paul1

I go to the Top-Level in Vcenter, klick "Alarms" and than "Definitions". Edit one of the definitions (don’t change anything) and then save it. After this the old alarms was gone in my environment

After “changing” the VM Memory Alarm definition, vCenter stops sending out false alarms.