CloudLinux running inside KVM kernel error?

[leemartin]

Hello,
We are currently operating a CloudLinux system with Plesk installed as a VM on Proxmox, running inside KVM. Recently, we encountered a kernel error (details below) and would like to understand what might be causing this issue.

The VM is configured with 2 sockets and 6 CPU cores, while the host has 2x L5460 CPUs. We have allocated 16GB of RAM, with the CPU type set to "host" and NUMA enabled.
geometry dash lite
The error occurred after only 3 hours of operation:

[ 8608.711786] Modules linked in: unix_diag udp_diag inet_diag ip6table_nat nf_nat_ipv6 xt_nat xt_multiport xt_set ip_set_hash_net ip_set nfnetlink kcare(OE) iptable_nat nf_nat_ipv4 nf_nat ip6table_mangle ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables iptable_mangle ipt_REJECT binfmt_misc nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c kmodlve(O) vzdev iptable_filter dm_mirror dm_region_hash dm_log dm_mod ppdev crc32_pclmul ghash_clmulni_intel sg bochs_drm ttm parport_pc parport drm_kms_helper aesni_intel lrw gf128mul glue_helper ablk_helper cryptd drm joydev i2c_piix4 virtio_balloon i2c_core shpchp pcspkr ip_tables ext4 mbcache jbd2 sr_mod cdrom ata_generic pata_acpi virtio_net virtio_console virtio_blk crct10dif_pclmul crct10dif_common

[ 8608.711850] crc32c_intel floppy ata_piix serio_raw libata virtio_pci virtio_ring virtio

[ 8608.711867] CPU: 3 PID: 71745 Comm: lvectl ve: 0 Kdump: loaded Tainted: G OE ------------ 3.10.0-962.3.2.lve1.5.25.10.el7.x86_64 #1 61.16

[ 8608.711871] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.2-0-gf9626ccb91-prebuilt.qemu-project.org 04/01/2014

[ 8608.711874] task: ffff8faf36b9b420 ti: ffff8faf9482c000 task.ti: ffff8faf9482c000

[ 8608.711877] RIP: 0010:[<ffffffff8cb66df5>] [<ffffffff8cb66df5>] copy_page_rep+0x5/0x10

[ 8608.711886] RSP: 0000:ffff8faf9482fd60 EFLAGS: 00010286

[ 8608.711893] RAX: 0000000000000200 RBX: ffff8fb000000055 RCX: 0000000000000200

[ 8608.711896] RDX: ffff8fb137cde040 RSI: ffff8fb32ff00000 RDI: ffff8faf20a00000

[ 8608.711899] RBP: ffff8faf9482fdd8 R08: 0000000000000001 R09: ffffe7c050bfc01c

[ 8608.711902] R10: 0000000000000200 R11: ffffe7c040828000 R12: ffff8faf9482fd58

[ 8608.711904] R13: 000011abd313633f R14: ffff8faf9482fd98 R15: ffff8fb0c23675e0

[ 8608.711908] FS: 00007fe350c20740(0000) GS:ffff8fb137cc0000(0000) knlGS:0000000000000000

[ 8608.711910] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

[ 8608.711913] CR2: 00007fe345ba5050 CR3: 00000000949fc000 CR4: 00000000000207e0

[ 8608.711920] Call Trace:

[ 8608.711927] [<ffffffff8c9dff41>] ? handle_pte_fault+0x5e1/0xce0

[ 8608.711939] [<ffffffff8c9e2607>] handle_mm_fault+0x397/0x9a0

[ 8608.711951] [<ffffffff8cf355d7>] __do_page_fault+0x197/0x4f0

[ 8608.711959] [<ffffffff8cf35a16>] trace_do_page_fault+0x56/0x150

[ 8608.711965] [<ffffffff8cf34fa2>] do_async_page_fault+0x22/0xf0

[ 8608.711973] [<ffffffff8cf31798>] async_page_fault+0x28/0x30

[ 8608.711982] Code: ff ff ff ff c3 90 9c fa 65 48 3b 06 75 14 65 48 3b 56 08 75 0d 65 48 89 1e 65 48 89 4e 08 9d b0 01 c3 9d 30 c0 c3 b9 00 02 00 00 <f3> 48 a5 c3 0f 1f 80 00 00 00 00 eb ee 66 66 66 90 66 66 66 90​

[bogdan.sh]

Hello!

That's interesting, it's something related memory overusage however, without details I can't say more. Do you have any other dumps or console screenshots when this happened? I wonder why this happened after 3 hours of operations, so can you confirm it was not in production with live clients on board?