ACPI funktioniert nicht auf VM mit CentOS 5.8 nur noch eine CPU von vier werden geladen

W

Winet.maier

Member
Proxmox Subscriber
Apr 21, 2023
58
5
8
Switzerland
www.ayrix.com
Guten Morgen
Wir haben noch ein paar alte Voiceswitche, die auf CentOS 5.8 laufen. Wir hatten denen 4 CPU zugewiesen und die liefen soweit stabil und gut. Wir wollten die Anzahl CPU auf 8 anheben und nach einem Neustart hatte die VM nur noch eine CPU. Egal was wir konfiguriert haben in der Hardwareeinstellung auf dem Proxmox die VM kam nur noch mit einer CPU hoch. Unser Techniker hat dann herausgefunden, dass es an den ACPI Einstellung liegen muss, welche beim Booten der VM Fehler schmeisst.

Ich vermute, dass nach dem Update auf PM 8.2.2 irgendwas schief gegangen ist.

Wir konnten das Problem mit dem Parameter acpi=force lösen. Ist meiner Meinung nach aber nicht ideal. Aus irgendeinem Grund wollten die VM's ACPI ja nicht laden.

Linux version 2.6.18-308.el5PAE (mockbuild@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-52)) #1 SMP Tue Feb 21 20:46:05 EST 2012
BIOS-provided physical RAM map:
BIOS-e820: 0000000000010000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000bffde000 (usable)
BIOS-e820: 00000000bffde000 - 00000000c0000000 (reserved)
BIOS-e820: 00000000feffc000 - 00000000ff000000 (reserved)
BIOS-e820: 00000000fffc0000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
BIOS-e820: 000000fd00000000 - 0000010000000000 (reserved)
4224MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000f5b60
Memory for crash kernel (0x0 to 0x0) notwithin permissible range
disabling kdump
NX (Execute Disable) protection: active
On node 0 totalpages: 1310720
DMA zone: 4096 pages, LIFO batch:0
Normal zone: 225280 pages, LIFO batch:31
HighMem zone: 1081344 pages, LIFO batch:31
DMI not present or invalid.
kvm-clock: cpu 0, msr 0:7489e1, boot clock
Using APIC driver default
ACPI: RSDP (v000 BOCHS ) @ 0x000f5950
ACPI: RSDT (v001 BOCHS BXPC 0x00000001 BXPC 0x00000001) @ 0xbffe3042
ACPI: FADT (v001 BOCHS BXPC 0x00000001 BXPC 0x00000001) @ 0xbffe2e14
ACPI: MADT (v003 BOCHS BXPC 0x00000001 BXPC 0x00000001) @ 0xbffe2e88
ACPI: SSDT (v001 BOCHS VMGENID 0x00000001 BXPC 0x00000001) @ 0xbffe2f18
ACPI: HPET (v001 BOCHS BXPC 0x00000001 BXPC 0x00000001) @ 0xbffe2fe2
ACPI: WAET (v001 BOCHS BXPC 0x00000001 BXPC 0x00000001) @ 0xbffe301a
ACPI: DSDT (v001 BOCHS BXPC 0x00000001 BXPC 0x00000001) @ 0x00000000
ACPI: Disabling ACPI support
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: BOCHSCPU Product ID: 0.1 APIC at: 0xFEE00000
Processor #0 15:1 APIC version 20
I/O APIC #0 Version 17 at 0xFEC00000.
Enabling APIC mode: Flat. Using 1 I/O APICs
Processors: 1
Allocating PCI resources starting at c4000000 (gap: c0000000:3effc000)
TSC: Frequency read from the hypervisor
Detected 2350.000 MHz processor.
kvm-clock: cpu 0, msr 0:38119e1, primary cpu clock
Built 1 zonelists. Total pages: 1310720
Kernel command line: ro root=/dev/vg/root
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c0771000 soft=c0751000
PID hash table entries: 4096 (order: 12, 16384 bytes)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 4143048k/5242880k available (2204k kernel code, 49784k reserved, 914k data, 232k init, 3276664k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop (skipped), value calculated using timer frequency.. 4700.00 BogoMIPS (lpj=2350000)
Security Framework v1.0.0 initialized
SELinux: Initializing.
SELinux: Starting in permissive mode
selinux_register_security: Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 178bfbff 2fd3fbff 00000000 02000000 f7f83203 00000000 008003f7
CPU: After vendor identify, caps: 178bfbff 2fd3fbff 00000000 02000000 f7f83203 00000000 008003f7
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 0(4) -> Core 0
CPU: After all inits, caps: 178bfbff 2fd3fbff 00000000 07080410 f7f83203 00000000 008003f7
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 14k freed
CPU0: AMD EPYC 7452 32-Core Processor stepping 00
Total of 1 processors activated (4700.00 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
Using local APIC timer interrupts.
Brought up 1 CPUs
sizeof(vma)=88 bytes
sizeof(page)=32 bytes
sizeof(inode)=340 bytes
sizeof(dentry)=136 bytes
sizeof(ext3inode)=492 bytes
sizeof(buffer_head)=52 bytes
sizeof(skbuff)=176 bytes
checking if image is initramfs... it is
 
Wir haben verschieden Mikrocode CPU Versionen ausprobiert. qemu32 und 64 über KVM32 und 64 aber auch x86-64-v3. Immer mit dem gleichen ACPI Fehler. Nur der Befehl ACPI=force hat geholfen und da wiederum konnte man wieder die CPU Typ wählen.
Fakt ist, dass das mal funktioniert hat und seit dem Update auf 8.2.2 nicht mehr. Wenn ich mich recht erinnere, waren wir auf 8.0.4 vorher. Wir hatte richtig Glück, dass wir den Workaround gefunden haben.
 
Habt ihr auch mal den Typ host getestet? Interessant wäre zu wissen, ob das mit dem Vorgängerkernel auch auftritt. Dann wüssten wir, ob es an dem Update liegt.
 
Hi,
bitte die Ausgabe von qm config <ID> für diese VM posten und die Ausgabe von pveversion -v. Im /var/log/apt/history.log wäre interessant nachzuschauen, welche Version von pve-qemu-kvm beim letzten Start der VM, als das Problem noch nicht da war, installiert war. Die Starts können z.B. in der Task History der VM gesehen werden.
 
fiona said:
Hi,
bitte die Ausgabe von qm config <ID> für diese VM posten und die Ausgabe von pveversion -v. Im /var/log/apt/history.log wäre interessant nachzuschauen, welche Version von pve-qemu-kvm beim letzten Start der VM, als das Problem noch nicht da war, installiert war. Die Starts können z.B. in der Task History der VM gesehen werden.
Click to expand...
Hier die qm config
root@pve02:~# qm config 241010123
boot: order=sata0;ide2
cores: 8
ide2: none,media=cdrom
memory: 4096
meta: creation-qemu=7.1.0,ctime=1676236083
name: FS-123
net0: virtio=BC:24:11:D1:B5:8A,bridge=vmbr0,firewall=1
net1: virtio=BC:24:11:56:4C:2A,bridge=vmbr1,firewall=1
numa: 0
ostype: l26
sata0: JOVIAN_COMP:241010123/vm-241010123-disk-0.qcow2,size=78G
scsihw: virtio-scsi-single
smbios1: uuid=d403552c-3b8d-4e51-9337-10be5a4a0f71
sockets: 1
vmgenid: ec7338b8-92ec-48ff-85df-563339f3f359

pveversion -v
proxmox-ve: 8.2.0 (running kernel: 6.8.4-2-pve)
pve-manager: 8.2.2 (running version: 8.2.2/9355359cd7afbae4)
proxmox-kernel-helper: 8.1.0
proxmox-kernel-6.8: 6.8.4-2
proxmox-kernel-6.8.4-2-pve-signed: 6.8.4-2
proxmox-kernel-6.5.13-5-pve-signed: 6.5.13-5
proxmox-kernel-6.5: 6.5.13-5
proxmox-kernel-6.5.11-7-pve-signed: 6.5.11-7
proxmox-kernel-6.5.11-6-pve-signed: 6.5.11-6
pve-kernel-5.4: 6.4-20
proxmox-kernel-6.2.16-20-pve: 6.2.16-20
proxmox-kernel-6.2: 6.2.16-20
pve-kernel-5.4.203-1-pve: 5.4.203-1
pve-kernel-5.4.106-1-pve: 5.4.106-1
ceph: 17.2.7-pve3
ceph-fuse: 17.2.7-pve3
corosync: 3.1.7-pve3
criu: 3.17.1-2
frr-pythontools: 8.5.2-1+pve1
glusterfs-client: 10.3-5
ifupdown: residual config
ifupdown2: 3.2.0-1+pmx8
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-4
libknet1: 1.28-pve1
libproxmox-acme-perl: 1.5.0
libproxmox-backup-qemu0: 1.4.1
libproxmox-rs-perl: 0.3.3
libpve-access-control: 8.1.4
libpve-apiclient-perl: 3.3.2
libpve-cluster-api-perl: 8.0.6
libpve-cluster-perl: 8.0.6
libpve-common-perl: 8.2.1
libpve-guest-common-perl: 5.1.1
libpve-http-server-perl: 5.1.0
libpve-network-perl: 0.9.8
libpve-rs-perl: 0.8.8
libpve-storage-perl: 8.2.1
libqb0: 1.0.5-1
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 6.0.0-1
lxcfs: 6.0.0-pve2
novnc-pve: 1.4.0-3
proxmox-backup-client: 3.2.0-1
proxmox-backup-file-restore: 3.2.0-1
proxmox-kernel-helper: 8.1.0
proxmox-mail-forward: 0.2.3
proxmox-mini-journalreader: 1.4.0
proxmox-offline-mirror-helper: 0.6.6
proxmox-widget-toolkit: 4.2.1
pve-cluster: 8.0.6
pve-container: 5.0.11
pve-docs: 8.2.1
pve-edk2-firmware: 4.2023.08-4
pve-esxi-import-tools: 0.7.0
pve-firewall: 5.0.5
pve-firmware: 3.11-1
pve-ha-manager: 4.0.4
pve-i18n: 3.2.2
pve-qemu-kvm: 8.1.5-5
pve-xtermjs: 5.3.0-3
qemu-server: 8.2.1
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.2.3-pve2
 
fiona said:
Hi,
bitte die Ausgabe von qm config <ID> für diese VM posten und die Ausgabe von pveversion -v. Im /var/log/apt/history.log wäre interessant nachzuschauen, welche Version von pve-qemu-kvm beim letzten Start der VM, als das Problem noch nicht da war, installiert war. Die Starts können z.B. in der Task History der VM gesehen werden.
Click to expand...
history-log ist mehr oder weniger leer und auf dem Cluster laufen über 400 VM's. Dürfte schwierig sein was zu finden.
 
Last edited:
Winet.maier said:
Ich bin mir zu 100% sicher, dass das am Update gelegen hat. Wir haben diese VM's vorher schon min. ein Jahr in Betrieb gehabt.
Click to expand...
Auch wenn das Update etwas geändert hat, könnte es ja hilfreich sein, andere Optionen zu testen. Ein super Beispiel ist das Problem mit OCFS, da hilft es auch die VM-Disks Async-I/O auf threads zu ändern. Natürlich kann man darauf bestehen, früher lief das immer so, aber anscheinend ja nicht mehr richtig. Ich ahbe schon ein Paar VMs gesehen, welche nach Updates etwas gezickt haben und nach Änderung der CPU auf host war es plötzlich OK. Ich würde es wenigstens testen.
 
Falk R. said:
Auch wenn das Update etwas geändert hat, könnte es ja hilfreich sein, andere Optionen zu testen. Ein super Beispiel ist das Problem mit OCFS, da hilft es auch die VM-Disks Async-I/O auf threads zu ändern. Natürlich kann man darauf bestehen, früher lief das immer so, aber anscheinend ja nicht mehr richtig. Ich ahbe schon ein Paar VMs gesehen, welche nach Updates etwas gezickt haben und nach Änderung der CPU auf host war es plötzlich OK. Ich würde es wenigstens testen.
Click to expand...
Wie gesagt, wurde getestet
 
Könntest du eine alte VM Konfiguration aus dem Backup zurückholen, ob da eventuell ein Schalter gesetzt war, der nach der Core Änderung anders ist?
 
Falk R. said:
Könntest du eine alte VM Konfiguration aus dem Backup zurückholen, ob da eventuell ein Schalter gesetzt war, der nach der Core Änderung anders ist?
Click to expand...
Wir habe ja an der Konfig nichts geändert. Lediglich nach einem Neustart wurden plötzlich nur noch eine CPU verwendet. Thats it.
Ich verspreche mir da gar nichts hier noch weiter zu suchen. Das ist eine Sackgasse.
 
Winet.maier said:
history-log ist mehr oder weniger leer und auf dem Cluster laufen über 400 VM's. Dürfte schwierig sein was zu finden.
Click to expand...
Es gibt auch die rotierten /var/log/apt/history.log.1.gz, vermutlich befindet sich darin das Update von pve-qemu-kvm. Wenn Du in der UI die VM ausgewählt hast, dann gibt es eine Task History wo nur die Tasks von dieser VM stehen.

Es gibt auch ein Paket von QEMU 9.0 im pvetest Repository. Falls es eine Regression war, ist das Problem da mit etwas Glück schon gefixt.
 
Winet.maier said:
Wir habe ja an der Konfig nichts geändert. Lediglich nach einem Neustart wurden plötzlich nur noch eine CPU verwendet. Thats it.
Ich verspreche mir da gar nichts hier noch weiter zu suchen. Das ist eine Sackgasse.
Click to expand...
Doch, ihr habt die Anzahl der Kerne geändert, hast du zumindest selbst geschrieben.
Ich habe es schon erlebt, das bei Änderungen in der GUI auch andere Optionen in den Konfigurationsdateien gerade gezogen werden, wenn die mal manuell verändert wurden oder gaaaanz alte Einträge haben, die heutzutage obsolet sind.
Das wäre der Punkt wo ich weitersuchen würde.
 
Falk R. said:
Doch, ihr habt die Anzahl der Kerne geändert, hast du zumindest selbst geschrieben.
Ich habe es schon erlebt, das bei Änderungen in der GUI auch andere Optionen in den Konfigurationsdateien gerade gezogen werden, wenn die mal manuell verändert wurden oder gaaaanz alte Einträge haben, die heutzutage obsolet sind.
Das wäre der Punkt wo ich weitersuchen würde.
Click to expand...
Das ist so nicht ganz richtig, in diesem Cluster waren auch VM betroffen, die wir NICHT angefasst haben. Soll heissen, dass die VM in ihrer, seit langem laufend Konfiguration, neu gestartet wurde und danach nur noch eine CPU hatten. Unser Monitoring hat danach hohen CPU load gemeldet, den wir falsch interpretiert haben, wer kommt den schon auf die Idee in der Konsole die tatsächlichen CPU anzusehen, wenn das Proxmox GUI mir sagt alles i.O.
Da es sich dabei um acht Voiceswitche mit Freeswitch gehandelt hat, hatten wir z.T. Qualitätsprobleme, zwar im unmerkbaren Bereich, jedoch mit der Depp Packet inspection, hat man schon gesehen, dass da was nicht optimal ist.
 
Da ihr anscheinend vor dem Reboot ein Update gemacht habt, hast du mal versucht den 6.5er oder notfalls den 6.2er Kernel zu nutzen?
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

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 yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom