 |
|
|
|
journal.txt: line 6 Linux version 3.10.0-1127.18.2.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) ) #1 SMP Sun Jul 26 15:27:06 UTC 2020 |
 |
This almost always ends up being a vmware problem. Check how loaded your host is - it looks like it's starving the guest of cpu time so it never gets to do any work, Did you actually read the 1.1MB mesages.txt file before you uploaded it? It's filled with snmpd diagnostic messages because you have the log level for it too high and there is nothing else of value in it at all. As for the gzipped attachment for the journal, not even going to bother downloading that as it's too big and too much effort. |
|
|
Update: attach filtered journal log, removing repeated messages like snmpd diagnostics, login sessions, postfix info etc. Relevant error messages: 593:Aug 20 17:08:25 vipdepot.vip.intern kernel: NMI watchdog: disabled (cpu0): hardware events not enabled 594:Aug 20 17:08:25 vipdepot.vip.intern kernel: NMI watchdog: Shutting down hard lockup detector on all cpus 3301:Sep 07 23:30:51 vipdepot.vip.intern kernel: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 40s! [snmpd:1047] What has happened before the error? I can see series of UDP connection diagnostics messages over half an hour, but there is for example no burst of them directly before the message. I consider the CPU starvation to be a valid argument, need to double check that. |
|
|
attachment |
|
|
Update: I've reviewed both VM's and its hosts monitors: no alarms were triggered. vCenter host CPU usage is below 50%. |
 |
Sometime in the past I worked for someone who proudly showed me that the physical processors were mostly unused and was firmly convinced that he can host 200 VMs on 4 processors. Until I started a "yum update" simultaneously on 50 machines and there was a 5 minute (!) delay between the moments the first machine started the update and the last one did the same Conclusion being that the error you see is triggered when the processors are starved, |
|
|
Hi there @ManuelWolfshant, we do not follow such a heavy overprovisioning style as in your example: for example, currently this host with its 32 logical processors serves 27 VMs. But I get the argumentation. Given there has been indeed a peak leading to high system load and CPU starvation: wouldn't be there a vcenter alert? |
|
|
I would not now and I do not care.. I quit using VMWare 10 years ago. Your question should be addressed in a vmware support venue. |
- Anonymous
