That's 60s long sequential write with 4k requests and normally never used in any comparing benchmarks.
What you wanted was "... --rw=randwrite ..." - so the fio cmd was maybe just a typo of yours.
The "ClamAVHeuristics" rule is broken and reports false positive "ClamAV heuristic test: Encrypted.PDF (clamav)" for PDFs that only have protected some permissions, see e.g. https://github.com/Cisco-Talos/clamav/issues/770
Not sure whether it will block updates, that might depend on the deployment method. cephadm might be more picky than others.
There's a different problem with having a cluster in HEALTH_ERR for a long time. During this period certain cleanups...
the patch series with the fix/workaround here: https://lore.proxmox.com/pve-devel/20260820131049.374072-1-c.ebner@proxmox.com/
those patches are included in pve-qemu-kvm >=11.0.3-3 and qemu-server >= 9.2.7
@uzumo : seems you are right!
The new 7.0.14-15-pve kernel with the mentioned fix appeared in the enterprise repository this morning. We're currently running it on one of our impacted production servers after some initial tests looked promising.
after the joyous adventure of making the backup run on the pve 8.2.2 machine, I can say that the symptoms are still the same there.
The 8.2.2 hardware is this:
CPU(s) 12 x Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz (1 Socket)
Kernel Version Linux...
128 GB und ARC bei 11 GB gedeckelt, da ist massig Luft. RAM/ARC würd ich damit erstmal ausschließen.
Bei der Kombi Dell + PERC im HBA-Mode würde ich eher in Richtung Storage-Hardware schauen, und im journal auf megaraid_sas/mpt3sas-Zeilen, task...
I ran into this exact issue today, and my cluster is now sitting at HEALTH_ERR.
As I understand it, this is a security warning regarding insecure key types rather than an immediate data loss risk, especially since the cluster isn't publicly...
@longer
It is a 2 node cluster with a QDevice.
Here they are:
Host 1:
cat /etc/network/interfaces
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to...
Could you share the network configs from 2 nodes where you observed the migartion issue and PBS connection problem:
cat /etc/network/interfaces
Just a hunch maybe its related to:
https://pve.proxmox.com/wiki/Roadmap#9.0-known-issues
Solange keine Portfreigabe drauf zeigt, bleiben die anderen CTs und VMs geschützt, die hängen im LAN und von außen kommt da nix an. Das Problem ist, wenn du einen Port aufmachst. Den Container würd ich dann in ein eigenes Netz hängen (eigene...
the patch series with the fix/workaround here: https://lore.proxmox.com/pve-devel/20260820131049.374072-1-c.ebner@proxmox.com/
those patches are included in pve-qemu-kvm >=11.0.3-3 and qemu-server >= 9.2.7
Recent security findings and fixes in Ceph make it necessary to upgrade ceph and migrate authentication keys from the aes to the aes256k cipher. This is to address weaknesses in the old Cephx authentication method, especially if your Ceph service...
Yes. We have done it. HAProxy runs in a small VM that is made HA through Proxmox itself.
The configuration looks like this:
global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket...
I just looked at the graph but I have a failing disk apparently. I just installed and already see checksum errors (disks are refurbished with runtime of about 6 years 50k hours)
root@pve:~# zpool status -P -v rpool
pool: rpool
state: ONLINE...
Der Host-Graph ist gar nicht so langweilig. Die Verwendet-Linie liegt die ganze Woche knapp unter Total, nur ein paar Dips nach unten. Genau da fängt PVE an, die Ballons aufzublasen, ab grob 80% Hostbelegung geht das los. Es trifft zuerst die VM...