Re: [PVE-User] Debian 11 hard lock issues as VM

[Bryan Fields <Bryan@bryanfields.net>]

On 1/17/23 3:22 AM, Eneko Lacunza via pve-user wrote:
> Hi Bryan,
> 
> We started to upgrade our cluster from PVE 7.2 to 7.3 yesterday.
> 
> I have enabled the agent in our only VM with Debian 11 running on a
> 7.3-4 node at the moment, and performed 5 full backups in a row, VM
> continues working (no hang).

This is replication, but I believe it's the same.

> You haven't provided details about your setup:
> 
> - Server (especially CPU model). Debian could be suffering from weird
> BIOS clock issues.

The Hosts are HP DL360's Generation 7.  ZFS Raid2 local storage using 1.6 TB 
SAS SSD's.  The life used indicator is now 6% or 7% on most disks.

There is 192 GB of ram in each server 16384 MB 1600 MHz ECC ram.

There are dual 3.07 GHz 6 core (12 thread) CPU's.  /proc/cpuinfo is below.

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 44
model name	: Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
stepping	: 2
microcode	: 0x1a
cpu MHz		: 1910.971
cache size	: 12288 KB
physical id	: 0
siblings	: 12
core id		: 0
cpu cores	: 6
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat 
pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx pdpe1gb rdtscp 
lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 
cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes lahf_lm epb pti tpr_shadow 
vnmi flexpriority ept vpid dtherm ida arat
vmx flags	: vnmi preemption_timer invvpid ept_x_only ept_1gb flexpriority 
tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs 
itlb_multihit mmio_unknown
bogomips	: 6134.18
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management:

the proxmox config for the VM is here:
agent: 1,fstrim_cloned_disks=1
bootdisk: scsi0
cores: 2
cpuunits: 2048
ide2: none,media=cdrom
memory: 8192
name: eyes.tampacoop.net
net0: virtio=86:49:26:AA:86:E7,bridge=vmbr199,firewall=1
net1: virtio=A2:C5:47:85:3E:3B,bridge=vmbr8
numa: 0
onboot: 1
ostype: l26
parent: before_extend
scsi0: local-zfs:vm-102-disk-0,discard=on,format=raw,iothread=1,size=48G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=11ed5a86-3395-49f2-ac80-16804b237a0d
sockets: 1
startup: order=1
vmgenid: 6238f0f2-ac90-43e0-b56c-05e1ed1c2431


> - Running kernel on PVE 7.3-4 . Kernel 5.15.x has been quite bad for us,
> have you tried kernel 5.13 or 5.19?

I reverted to 4.9.0-19-amd64 #1 SMP Debian 4.9.320-2 (2022-06-30) x86_64 
GNU/Linux Kernel on the guest OS and it's not locked up once now.  This is 
running either the 5.2.0 or 7.2.0 agent.

I've moved the VM's across hosts and they have the same problem.

FingerlessGloves mentioned there was the possibility of this being a mariadb 
issue and I can confirm we have the official Maria DB packages installed on 
this server.  10.10.2-MariaDB-1:10.10.2+maria~deb11 is what we're running on 
the server.

Could this be some interaction of new kernel and new maria db?

-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net