Recent content by winproof

i try, thanks

@Jerome69 Hello, have you solve your problem? i have exactly the same (data fabric sync flood event error) with a Ryzen Embedded R2514 (Gmktec G11 minipc). i've try everythings (memtest86, ssd check, disable "processor.max_cstate" & co from cmdline, disable all bios power/sleep options), no...

dell is working on it, they were able to reproduce the problem on their side and are looking for the cause. Apparently it's not hardware, probably a BIOS problem that will be solved by an update.

me too! :p

i confirm :) before self-test : root@pve2-r250:~# cat /proc/cpuinfo | grep "MHz" cpu MHz : 3401.182 cpu MHz : 3404.657 cpu MHz : 3399.991 cpu MHz : 800.000 cpu MHz : 800.000 cpu MHz : 800.000 cpu MHz : 800.000 cpu MHz : 1890.949...

okay, I think I've found the root of the problem! really vicious, in fact it has nothing to do with the zimbra VM, proxmox or with the network.... in fact the problem appears every time my UPS management software runs a self-test (every 2 weeks in my case) it's obviously a hardware problem on...

ok, all firmwares are up-to-date. but TX201 still use r8169 driver, I haven't yet tried using the driver supplied by tp-link. this weekend I will try to make the backup using integrated network card, to remove the 3rd link (used only for migration, corosync is in another link) just delete...

i try, thanks

no, fstrim is scheduled one time per week, monday at 00:00 (ubuntu 20.04 default) nothing in zimbra log. and no, zimbra is not EOL, it's right only for zimbra 9 community edition (free), we use zimbra 10 network ed. :) it's probably not something related to zimbra, because no problem when this...

and i can confirm that, a cluster reboot not solve the problem, only a complet shutdown solve the problem...

argh, problem has reappeared... help!!!:eek:

ok, problem "solved" (or rather it disappeared :)) after making a clone of the zimbra server and replace the original server. apparently there is something wrong with the vm, bad virtual disk image maybe? but it's still strange that a bug on one vm causes this kind of behavior on the other vms...

ok, so doing a live migration of the zimbra vm to the 3rd node (DELL T430) , then restarting the cluster solved the problem again. but I just noticed something. when I restarted the cluster this morning for the first time (without having moved the vm), I had the impression that the first 2 nodes...

and just in case, i've forgot to reply to this: no, my zimbra vm not use zfs storage inside, just classic LVM.

Wednesday (it's a holiday in my country) I'm going to do another test, put the vm back on one of the nodes with zfs and an nfs share, and do a backup again, but this time using the "normal" network and not the 2.5Gb link, just to see if it makes a difference....