Search results

This is with metadata mode. Default is worse with checksum.

do you have tried to reinstall proxmox-widget-toolkit ? apt install --reinstall proxmox-widget-toolkit

lxc backup is scanning all files to see if metadatas (modification time) have changed , so if you want millions of small files, it can put load on the disks even if you don't have changes. vm backup use internal qemu dirty-bitmap tracking, so when backup is starting, it's directly known which...

you can do "qm rescan" in command line, it's import the disk 101 in the vm configuration.

it's not a super good idea to use corosync over active-backup bond. see: https://pve.proxmox.com/wiki/Cluster_Manager at minimum, configure bond-primary to be sure to have the correct interface up by default, verify that all active interfaces are correctly on the same switch. and if only the...

you can use "corosync-cmapctl -m stats" on each node to have detailed stats about latencies && message retry/loss

you need to create 2 custom crush rules using the device_classes ceph osd crush rule create-replicated <crush_rules_name> default host <device_class> ex: ceph osd crush rule create-replicated myhddreplication default host hdd ceph osd crush rule create-replicated myssdreplication default...

do you have a granular monitoring (prometheus,...) which can check bandwidth every second ? don't trust average. do you have also checked your switch port buffer stats ? if it was a kernel bug, you'll have too on your 10gbit nic. I'm running 100 nodes in production without any problem. I...

no, the mlag is only on your switch side. on pve host, it's a classic bond. do you have tried with linux bond instead ovs ?

but you have packet loss, this is even worse. (you can look at corosync stats too yes, definitively the recommandations is to have dedicated links for corosync https://pve.proxmox.com/pve-docs/chapter-pvecm.html but note that last corosync version sur dscp protocol...

This could be related to memory fragmentation. do you use zfs ?

I don't think that microcode has never been in pe-firmware package. It's always the debian package. (and debian can be a little bit slow to update them)

you can try the firmware from debian testing: http://ftp.de.debian.org/debian/pool/non-free-firmware/a/amd64-microcode/amd64-microcode_3.20251202.1_amd64.deb (or upgrade your bios if your vendor provide it)

basically, if you have network saturation, the latency increase, and corosync remove the node from the cluster. (down/up don't mean that the physical link is flapping, it's simply that the node where you are checking the log, don't have a response enough fast from the remote node, and display...

Well, you cant just pass all flags blindly. Some Windows versions can crash, some flags like tlbflush can have performance impact dépending of the workload,....

Is the 1gb link dedicated to corosync ? Link saturation could give flap like this.

The hv* flags are already send to command line by proxmox when you choose Windows as ostype.

Osd need to talk to monitor and clients (vm) which are running in public network, so they always use both public and private network

please don't double post, https://forum.proxmox.com/threads/applying-pve-qemu-kvm-10-2-1-1-may-cause-extremely-high-%E2%80%9Ci-o-delay%E2%80%9D-and-extremely-high-%E2%80%9Ci-o-pressure-stalls%E2%80%9D-patches-in-the-test-repository.182186/page-2 the thread here is about Hi, please don't...

the thing is that the host itself don't mount the rbd. It's done directly by each qemu process. the librbd is inside qemu, and this is the qemu process which is doing to connections to monitor && osd. (with kbrd it's different, as it's done by the host, but I don't have any experience with it...