Search results

1. pve-qemu-kvm=9.2.0-3 aus dem Test-Repo installiert 2. VMs heruntergefahren 3. -machine hpet=off aus der args Zeile entfernt 4. VMs (Kubuntu und Debian) gestartet und gefreut

Getestet mit Kubuntu2404 und Debian12.10 VMs .... CPU-Auslastung ist nun auch ohne argsEintrag, wieder dort (sogar ein wenig darunter) wo sie bei 9.0.x-x war! Danke für den schnellen Fix!!

I assume you have also updated pve-qemu-kvmto 9.2.x-x Have a look there: https://forum.proxmox.com/threads/plötzlich-höhere-cpu-last-bei-allen-linux-vms.163694/

1. proxmox shell einfach die args datei der vm öffne mit "nano /etc/pve/qemu-server/<vmid>.conf" 2. dann kann ich hier auch den Eintrag "machine hpet=off" setzten ---> falls da bei "args" schon was steht nur den Eintrag erweitern 3. shutdown der maschienen 4. Upgrade auf neue version 5. reboot...

Kannst du natürlich machen ... Aber Qemu 9,2 bringt schon einige Verbesserungen mit! Die von @fiona geposteten Änderungen an der/den VM-configs ermöglichen sogar einen geringeren Energieverbrauch, bei (gefühlt) besserer Performance.

I tested the installation with the recommended 8GB RAM and it worked without any problems! Authentik is very resource-heavy, it is recommended to use at least 8GB RAM anytime!

Du musst keinen Shutdown des PVE-Hosts machen, nur von der VM wenn du die neue QEMU Version 9.2 nutzen willst.

Ohne Shutdown wurde die neue QEMU-Version bei dir nie aktiv! Neustart ist zu wenig. Das "Problem" ist bei dir noch in der Warteschleife, und wird irgendwann kommen ...

Ich habs oben schon editiert. Ich hatte schon einen "args" Eintrag (für 9p mounts) in der Config, der nach dem Befehl natürlich weg war und den Start verhindert hat. Hab die config manuell editiert, und läuft super! Danke für die Hilfe

Ich hab den Befehl getestet und bin im Rescue-Mode der VM gelandet (weil keine fstab mounts möglich waren). Die CPU-Auslastung war dabei aber super niedrig ;) Edit: Auch bei mir ist mittlerweile alles OK. Das Problem war, dass ich schon einen "args" Eintrag in der config hatte, der mit dem...

Der verhindert halt, dass bei zukünftigen Updates die qemu Version 9.2 wieder installiert wird. Mit apt-mark unhold pve-qemu-kvm wär der Befehl auch wieder schnell rückgängig gemacht ... ;)

apt install pve-qemu-kvm=9.0.2-5 apt-mark hold pve-qemu-kvm=9.0.2-5 ... und alle betroffenen VMs herunterfahren und neu starten (bei solchen Sachen bin ich mir nicht sicher ob ein Reboot ausreichend ist)!

In meinem Fall wäre das: PVE: 16 x AMD Ryzen 7 5700U with Radeon Graphics (1 Socket) - 32GB RAM - EFI - pve-manager/8.3.5/dac3aa88bac3f300 VM209: Debian 12.10 (war beim Test am Mittwoch noch 12.9) - 1 CPU [host] - 1,5 GB RAM - Fileserver 45drives Kernel PVE: 6.11.11-1-pve VM209...

Try using this command to delete memory space from the log file: journalctl --vacuum-size 64M

Keine Ahnung, ich verwende/kenne das Script nicht. Aber es gab damit schon mal solche Probleme, wie du sie beschrieben hast ... War ja auch nur eine Vermutung meinerseits.

Hatte dasselbe "Phänomen". Kam bei mir mit dem Update von pve-qemu-kvm auf 9.2.x-x Ich bin nach 5 Stunden wieder zurück auf 9.0.2-5 Seltsamerweise habe ich damals mit TOP keinen Prozess finden können der die Last verursacht hat ....

PBS does not use compression, but deduplication.

Hast du irgendwelche "seltsame" Scripte am laufen? Konkret erinnere ich mich noch dass Proxmox VE Cron LXC Updater solche Probleme verursacht hat ....

Bei Containern musst du nicht mehr machen, als die gewünschte Platte im GUI ( 20GB) zu vergrößern. Ist nichtmal ein Neustart notwendig. Ressourcen --> Root-Disk --> Volumen-Aktionen

Dein Router ist dein DNS-Server für das lokale Netzwerk. Also würde ich die IP vom Router als DNS1 verwenden. Ich habs so eingestellt (GoogleDNS nur als Backup).