You are right,
I just checked the Debian package tracker and version 1.4.6 is indeed flagged as "A new upstream version is available... consider packaging it.":
https://tracker.debian.org/pkg/clamav
Seems the Debian maintainers haven't compiled...
We do this for all upgrades. We probably should have done this on all nodes straight away when it was in this state, but you live and learn right.
Disarming HA should have probably been our first step.
ClamAV updates automatically via the clamav-freshclam.service, which run continuously in the background.
Check:
~# systemctl status clamav-freshclam
PMG uses clamav from debian upstream - once they have an updated version - you will get it...
If you have not done so yet, save system journal from each host as far in the past as it allows you. At this point its probably your only lifeline to RCA. I know the hindsight is 20/20, but the best time for data collection was, unfortunately...
That was the only node that didn't have fast set.
We think we had something further back that caused an issue on dbus and eventually we got a lock on the fusefs, and corosync just eventually died and rebooted everything.
We're evaluating...
I am not exactly sure if this the current issue you observed, but since bonding is used, the following recommendation from Proxmox documentation applies:
See 5.8.2. Corosync Over Bonds...
I apologise, I miss interpreted the log, for Linux vm virtaio driver not an issue (mostly).
I would consider using Virtio and investigating further, e.g:
Check journalctl log in pve and vm.
consider enabling multiqueue.
Make sure the path...
I wonder if this is might be due to page cache pressure or dirty page writeback stalls? A reboot might clear transient memory fragmentation.
Did you notice it occurs after sometimes or it was always like this?
I have no experience on this, but I found this thread which explains it can causes issue:
https://forum.proxmox.com/threads/web-ui-shell-disconnects-with-code-1006-%E2%80%93-root-cause-igmp-proxy-snooping.178761/
You are right, for corosync the recommendation is to have latancy below 5ms.
I would not activate HA in such setup because it might lead to a lot of fences (reboot).
Would not be wrong, ensuure low latency.
if switch support qos then you can attempt too configure the switch so that it prioritise corosync traffic.
Do not forget to configure migration network, Ideally should be on a separate nic as well...
Found the issue - was my fault - from an prior installation on other hardware (without boss card), there was still "GRUB_CMDLINE_LINUX="root=ZFS=rpool/ROOT/pve-1 boot=zfs" in the grub-default-file…
Thanks for comments!!
Thank you for the suggestion.
Unfortunately I cannot test with an older kernel at the moment because this is my production homelab. However, I can schedule a maintenance window and test both kernel 6.14 and 7.0.14-8-pve if this would help narrow...
I had a different issue while importing Debian11 and Ubuntu 12, for me it didn't boot at all, and only after switching to SATA it worked.
therefore this is Just my 2 cent here, I would try since its quick change to switching the virtual disk bus...