4.15 based test kernel for PVE 5.x available

Interesting enough everything seemed fine on our new(er) hardware until I started optimizing BIOS settings for our workload. Using HPE's document to optimize for low latency recommends disabling a few features that caused these kernel panics for me.

The relevant settings are:

Intel Virtualization Technology -> disabled

Intel Hyperthreading Options -> disabled

Intel Turbo Boost Technology -> disabled

Intel VT-d -> disabled

What's odd though is I have to keep them all enabled since pve-kernel 4.15.18 while 4.15.17 was fine with these disabled.

(We use 3 nodes just for storage with a Proxmox install to simplify the CEPH installation process, otherwise these settings obviously should be enabled except for Hyper Threading perhaps)

Perhaps someone else running into this issue might want to check these settings, I'll leave them enabled for now.

Staff Member

What's odd though is I have to keep them all enabled since pve-kernel 4.15.18 while 4.15.17 was fine with these disabled.

Click to expand...

That is very very strange, with all those virtualization flags disabled you should have been never able to boot any VM with us (at least if you do not set 'kvm' manually to off)..
Please never turn them off.

Hello,
I also have the same problem with 2x Xeon e5 2680v2 on supermicro x9drw-if, latest bios and pve.
Crashes with the same message, additionally I have one of the 10g links (x520-da) flapping since.
However, removing the Intel-Microcode package seems to hhav stabilized it a bit.

then set units as cluster members ad after some "blank" runtime days,
moved some VMs to the new nodes (these are the newer nodes then we've moved there the most expensive VMs!)

all seems to run fine for many ours (i think one or two full days at max!)
then users started to report extremely slow response from the terminal server and really long query response time from MySQL linux VM!

after some rapid checks,
we've moved VMs back to the older nodes (still running 4.13.x kernel!)

then magically issue seems to have solved, normal response time from both VMs....

actually rolled back units to 4.13.x kernel,
then restarted units and after some testing time, moved VMs back to newer nodes!

now all running fine!
our cluster updates have been locked to 4.13.x kernel branch!!

Quick Navigation

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get your own in 60 seconds.