Search results

Den Ordner /dev/drischickst du mehrmals in den Container. Als devx:und alslxc.mount.entry: Möglicherweise ist das ein Problem. vainfoSchaut aber OK aus.

Dann ist der Speed halt immer noch vom Netzwerk (siehe Post von @Falk R. ) abhängig. Mach einfach den Versuch, mit der Hardware die du rumstehen hast. Vielleicht reicht es für dich ja. Ich hab früher auch meine DS218p als PBS-BackupStorage über NFS genutzt. Weil es halt soooo langsam war, hab...

Probiere es einfach aus, es wird funktionieren! Wenn du mit der Performance zufrieden bist, dann nutze dein NAS als PBS-Storage. Aber GC- und Verify-Jobs werden eben viel Zeit benötigen.

Welchen Speicher hast du im NAS verbaut? Ich vermute HDDs? Das ist absolut nicht ideal für den PBS, der jedes Backup in hunderttausende kleine chunk-Dateien aufteilt und speichert.

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 ....