CentOS7 Latest Kernel Still Does Not Run KVM Guests
The two latest kernels for CentOS7 are complete fails for running KVM
and QEMU guest machines.
Version 3.10.0-1160.76.1 works correctly. Both 3.10.0-1160.80.1 and
3.10.0-1160.81.1 will hang within seconds of launching any virtual machine. It is a HARD hang. I have to pull the power cord from the computer in order to regain control.
Since 81.1 came out within the last few days, I assumed it would contain a fix for this problem. It does not.
Does anyone know when a kernel will be released that fixed this problem?
7 thoughts on - CentOS7 Latest Kernel Still Does Not Run KVM Guests
This is not true for all KVM guests. This kernel is actually installed and test booted before release on a cold iron, KVM VM, Virtual Box VM, and ESXi VM.
It also passes our t_functional test suite:
All C7 updates run through all these tests for all new rpms.
So this problem has some other specific cause. Is this on a E5507
processor?
What OS is the KVM host running. I assume this is x86_64 arch?
Oh, here is a list to the test suite:
https://github.com/CentOS/sig-core-t_functional
Hi Johnny –
Yipes, I hate problems like this!
The host computer is a SuperMicro C2SBC-Q mainboard. The processor is an Intel Core2-Quad Q9400. Yes, it is x86_64 architecture. The display adapter is an older nVidia GeForce 8400 GS, and I use the nouveau driver for it. Selinux is disabled.
The guest machines are Fedora 37 and CentOS7.
So far I have found no log files with anything useful. The hang happens so quick that nothing gets logged. Here is a section of
/var/log/messages. Notice the gap at 06:32 to 06:43. This is where I
started a virtual guest and the system hung. At reboot I chose a different kernel.
======================
Dec 20 06:32:26 practice7 systemd: Starting Fingerprint Authentication Daemon… Dec 20 06:32:26 practice7 dbus[750]: [system] Successfully activated service ‘net.reactivated.Fprint’
Dec 20 06:32:26 practice7 systemd: Started Fingerprint Authentication Daemon. Dec 20 06:32:26 practice7 dbus[750]: [system] Activating via systemd:
service name=’org.freedesktop.realmd’ unit=’realmd.service’
Dec 20 06:32:26 practice7 systemd: Starting Realm and Domain Configuration… Dec 20 06:32:26 practice7 dbus[750]: [system] Successfully activated service ‘org.freedesktop.realmd’
Dec 20 06:32:26 practice7 systemd: Started Realm and Domain Configuration. Dec 20 06:32:48 practice7 systemd: Starting Stop Read-Ahead Data Collection… Dec 20 06:32:48 practice7 systemd: Started Stop Read-Ahead Data Collection. Dec 20 06:43:08 practice7 journal: Runtime journal is using 8.0M (max allowed 391.0M, trying to leave 586.5M free of 3.8G available → current limit 391.0M). Dec 20 06:43:08 practice7 kernel: microcode: microcode updated early to revision 0xa0b, date = 2010-09-28
Dec 20 06:43:08 practice7 kernel: Initializing cgroup subsys cpuset Dec 20 06:43:08 practice7 kernel: Initializing cgroup subsys cpu Dec 20 06:43:08 practice7 kernel: Initializing cgroup subsys cpuacct Dec 20 06:43:08 practice7 kernel: Linux version
3.10.0-1160.76.1.el7.x86_64 (mockbuild@kbuilder.bsys.CentOS.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Wed Aug 10
16:21:17 UTC 2022
==========================
Is there anyplace else I should look for log files? Is there a way to get verbose logging?
How might I check for a kernel panic? The display never says anything about a kernel panic – it just hangs.
Thanks!
===============
Bill Gee
I have had two different Router machines do something similar on the IPFire OS, and the core cause ended up being power related. —
Christopher Wensink IS Administrator Five Star Plastics, Inc
1339 Continental Drive Eau Claire, WI 54701
Office: 715-831-1682
Mobile: 715-563-3112
Fax: 715-831-6075
cwensink@five-star-plastics.com http://www.five-star-plastics.com
Hmmm…. I have dealt with bad power supplies. I doubt it is the problem in this case. If it were a power supply, then why does the system work perfectly on the older kernel?
In fact, the system runs great on the newest kernel, right up to the point where a VM is started. It will run for days as long as I never start a VM. Start a VM and BAM! It is hung hard.
===============
Bill Gee
“In fact, the system runs great on the newest kernel, right up to the point where a VM is started. It will run for days as long as I never start a VM. Start a VM and BAM! It is hung hard.”
Are you required to use “official supported kernels” or do you have some flexibility? My main KVM host is a CentOS 7 box and I’m using kernel-ml from elrepo-kernel. The kernel version usually tracks with recent kernel releases- on my el9 boxes it’s currently at 6.1- but I’m running 5.19 on my CentOS 7 KVM host with no issue.
CentOS mailing list CentOS@CentOS.org https://lists.CentOS.org/mailman/listinfo/CentOS
There is https://bugzilla.redhat.com/show_bug.cgi?id=2143438 which I ran into on AlmaLinux 8, (which impacts Xeon 55xx processors, but seems to work on Xeon 56xx and newer).
Just a user who ran into it (nothing to do with the fix), and I upgraded the server to a Xeon 56XX processor to resolve it. (an ancient Intel S5520HC board)