.
As mentioned in the Serial Terminal wiki [0], you can configure a VM's serial console to listen on a local TCP port instead of the default socket:
By doing this, the Proxmox VE host exposes the VM's serial console through a raw TCP socket...
Since you haven't measured anything yet, I'd confirm there's a real problem before chasing the message. In the guest, run this before a migration and again straight after:
chronyc tracking
Watch System time and Last offset. If both stay small...
This creates spikes that are well above munin defaults for sending emails. And these defaults are set by munin maintainers ?
It's 0:3 by default (warning/email if above 3 seconds). It's like that since 20 years I believe...
WARNINGs: Write IO...
This is a side-topic, not related to the problem directly:
Qemu has a watchdog, called i6300esb - which should reboot a frozen vm.
config:
watchdog: model=i6300esb,action=reset
(not officially supported in proxmox)
But don't bother, it doesn't...
If this ever gets to a kernel developer : this is super easy to replicate ; just add munin package on a vm or LXC, or even on the host itself.
monitoring disk latency is default.
pve devs say for -6
update submodules and patches to...
I just now had to downgrade on production from 7.x to 6.x
I tested q35, ver 11.0+pve2, cpu qemu x86-64 v3 - still freezes, this time at 80% cpu (so the range is now 40% - 80%)
So this is not related:
"The patch is already included in QEMU Server...
I'm back at -5 and the problem vanished .
So basically the problem appeared in -6 (as per Galaxis) , is still there in -8, I was just a bit late in the game.
If it's a new kernel feature and not the sign of the disks getting crazy, it sure...
Hey! Sorry, I completely missed your reply, and I apologize for getting back to you so late.
Unfortunately, I'm primarily a macOS developer and don't have a Windows machine. Also, I have to admit that C# isn't really my favorite language to work...
Since @weppa writes it was still fine in -5 (which I skipped coming from -4), and the effect first showed up for me in -6, something must have happened between those two versions.
Thanks @Neobin !
In the meantime
proxmox-boot-tool kernel pin 7.0.14-5-pve
proxmox-boot-tool refresh
UPDATE : I can confirm the problem DISAPPEARS with kernel 7.0.14-5
So it's specific to kernels after this one.
Since @weppa writes it was still fine in -5 (which I skipped coming from -4), and the effect first showed up for me in -6, something must have happened between those two versions.
I agree that GitOps, Ansible, sudo, and similar tooling are all valid operational approaches. My point isn't that there are no workarounds. My point is that the supported first-party GUI still lacks an enterprise identity model for host lifecycle...
Well, you can limit the sudo priviledge by specifying the exact commands that should be capable to run.
(e.g. %test ALL=(ALL:ALL) /usr/bin/apt update, /usr/bin/apt upgrade -y) and sudo logs all actions to journalctl
If you like to try out a...
Have you checked this https://forum.proxmox.com/threads/advice-needed-upgrade-pve-8-to-9-using-systemd-boot-with-zfs-rpool-uefi-and-no-secure-boot.181956/
Thanks,
lsblk -f
shows a UUID for the EFI System Partition, so I don't think this solution applies to my case.
I also don't want to reformat the ESP without knowing that it is actually the problem.
Thanks for this suggestion. I will need to run this tonight during a quieter period since i do have production running. Would a smaller sample, such as 32 GiB, still provide a useful comparison between TrueNAS, PVE01 (node 1), and PVE99 (node 2)...
I think the main issue with adding such a feature to the API would be that anybody who can do system upgrades basically gets "root" powers. So if your compilance requirements are that you need to limit the potential breakage done by a single...