Search results

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

Hello the problem just happened again :( and more or less at the same time, sunday 7pm. reboot all nodes not solve the problem. but now I have a clearer idea of the cause, it's somethink caused by an interaction between one of my VMs (the one with zimbra) and the ZFS or the nfs share used for...

so, after a reboot of all nodes, the situation is back to normal, no more high cpu usage not sure if it's because of the reboot or because of the replication tasks deleted, but problem solved apparently:) it's just a shame that there's nothing in the proxmox logs, because then we'll never know...

nope, no cooling problem. root@pve1-r250:~# sensors coretemp-isa-0000 Adapter: ISA adapter Package id 0: +40.0°C (high = +90.0°C, crit = +100.0°C) root@pve2-r250:~# sensors coretemp-isa-0000 Adapter: ISA adapter Package id 0: +36.0°C (high = +90.0°C, crit = +100.0°C) root@pve3-t430:~#...

hum, on second node : root@pve2-r250:~# journalctl | grep kernel.perf Apr 06 18:40:01 pve2-r250 kernel: perf: interrupt took too long (2502 > 2500), lowering kernel.perf_event_max_sample_rate to 79750 Apr 06 22:51:51 pve2-r250 kernel: perf: interrupt took too long (3151 > 3127), lowering...

yes, find nothing specifique, no backup/replication at this time. only backup very early sunday, ended before 12:00 no replication during week-end root@pve2-r250:~# journalctl --since "2024-04-14 16:00:00" --until "2024-04-14 21:00:00" Apr 14 16:11:20 pve2-r250 pmxcfs[1119]: [status] notice...

ok, makes sense for a mail server, but i can see the same thing for my DC (Samba ad only, nothing more, on debian 11) previously never more than 1%, now 9-10% ? with absolutely no change.

hum i can understand that zfs impact cpu use on the host, but why on the guest?