This is where the problem starts for people with VMware HA enabled. I’ve heard rumors that some people have seen these core dumps take as long as 20 minutes. In rare cases though, it might take longer. Normally, this core dump occurs very rapidly – less than a minute in most cases. Once this process is finished, the user will see a PSOD. This includes the locks on any datastores used by VMs that were running. During the time that the VMkernel is performing the dump, it tries to keep everything exactly like it was when the problem with the COS occurred until after the dump completes. Of course, this is all compressed so as to save space. This core dump is invaluable for troubleshooting and basically consists of an entire dump of memory as well as some additional overhead. When the COS becomes unresponsive or throws an error, the VMkernel detects this and starts to generate a core dump.
For example, there may be a memory leak in a process, a third party application consuming a large amount of memory, or excessive numbers of processes running in the COS. This can be due to a variety of reasons, but commonly it is due to an issue withmemory. Sometimes, the COS may become unresponsive. It is possible, however, and for those who have experienced it, I hope that this makes things a bit clearer.ĮSX, as you know, has what we refer to as the ‘COS’, or Service Console. Odds are you likely have not seen it, nor will you. What I am about to describe is a rare corner case. Let me explain why:īefore I gointo details here, let me first make absolutely clear a very important point. There does exist a corner case where this may not be the case. In a HA protected environment, if a PSOD does occur you would expect that the VMs that were running on the host that encountered the PSOD would be failed over to another host. PSODs can occur for a wide range of reasons, including out of memory and hung CPU conditions. Despite our best efforts here at VMware, there are occasions where a PSOD may occur.
0 kommentar(er)
