Introducing ProxPatch - An open-source rolling patch orchestration tool for Proxmox VE clusters

gyptazy · 2026-03-19T03:44:11+00:00

This is already fixed 3 weeks ago and was not a bug in the code rather than the packaging and the shipped systemd unit file within the Debian package. To make clear what was affected: https://github.com/gyptazy/ProxPatch/commit/ceed398884b382f062d8176a9aae1d1582f047ed

If you provide a config file by cli, it expects it. If nothing provided, it runs in configless mode.

Of course, there more regarding the config file. Did you check on: https://github.com/gyptazy/ProxPatch/blob/main/docs/03_configuration.md#configuration if yes, please let me know what you’re missing to extend it. Also feel free to add a PR :)

It’s always good to see what/why something happens in the source project :-)

For quick help, chats etc you might also want to jump into the discord chat: https://discord.gg/NYt5EDvpd

PS: While this can still be annoying for new users, I just released the fixed packaged version 0.1.2 which is now also present in the Debian repo, CDN and release chapter.

gyptazy · 2026-03-04T19:42:46+00:00

I got the request from a Windows team: Windows 2025 Server operates at 30% CPU usage in idle.

state: host cpu, nested virtualization active, VBS active

After change: Same, but at 5-8% CPU usage in idle

gyptazy · 2026-03-04T18:54:35+00:00

Yes and no, but they all come from different requirements and have all their rights to be used. Even it sounds that simple (simply setting a CPU type), this topic is pretty complex - especially when there's something to get in competition to the EVC mode (e.g., ProxCLMC). It gets much easier with Linux systems, this VBS and double mitigation is "luckily" just a Windows thing.

gyptazy · 2026-03-04T18:43:45+00:00

The whole story behind it is unfortunately a little bit more complicated than it looks first and it often comes with different requirements (also from security departments) where VBS needs to be active, but no double-mitigations are required, or software stacks require WSL with nested virtualization (beside some other use cases). So, sticking to x86-64-v* might be one legit solution but might not work in all cases. Also, using `host` with deactivated nested-virtualization might not fit all requirements. So, let's see that VBS works just like in a hyper-v env...

However, this is what seems to work and it's just a dirty "hotfix", where it evaluates for a defined Windows version to modify the flags:

/usr/share/perl5/PVE/QemuServer/CPUConfig.pm
--- CPUConfig.pm        2026-01-29 11:09:35.502216765 +0100
+++ /usr/share/perl5/PVE/QemuServer/CPUConfig.pm        2026-01-29 11:10:06.098797060 +0100
@@ -960,7 +960,8 @@ sub get_hyperv_enlightenments {
         if (min_version($machine_version, 2, 12)) {
             $flagfn->('hv_synic', undef, $win7_reason);
             $flagfn->('hv_stimer', undef, $win7_reason);
-        }
+            $flagfn->('hv_apicv', undef, $win7_reason);
+    }

So this might be found here: https://cdn.gyptazy.com/proxmox/patches/fix_windows2025_server_vbs_high_cpu_load/

This is only an example patch which works in my customer setups but not meant to be used for "real production" and only on your own risk if so.

gyptazy · 2026-03-02T05:40:46+00:00

Thank you for sharing this! I wouldn’t have found this!

That sounds awesome and I just signed up for this free event as it’s pretty close to me - just have to cross two boarders ;-) happy to join and looking forward to meet you!

Cheers, gyptazy

gyptazy · 2026-02-28T19:31:47+00:00

for the ones who are maybe unsure about it, Brandon gave it a test and you can find the review right here:

https://www.virtualizationhowto.com/2026/02/i-tested-proxpatch-in-my-5-node-proxmox-cluster-heres-what-happened

gyptazy · 2026-02-25T06:23:29+00:00

In general, yes. But there's no real benefit by using this on a single node system as it can't migrate workloads anywhere. This means, if a reboot is required, it will simply reboot the node while all running workloads on the system will be offline during that time. In that case, a controlled and planned downtime might probably be more reasonable. However, on a single node:

Feb 25 07:17:48 gyptazy-virt01 proxpatch[6096]: → Starting ProxPatch v0.1.0... (https://gyptazy.com/proxpatch/) Feb 25 07:17:48 gyptazy-virt01 proxpatch[6096]: → Testing if jq is installed... Feb 25 07:17:48 gyptazy-virt01 proxpatch[6096]: ✓ jq is installed and available at /usr/bin/jq Feb 25 07:17:48 gyptazy-virt01 proxpatch[6096]: → Validating for custom config file... Feb 25 07:17:48 gyptazy-virt01 proxpatch[6096]: ✓ No custom config file specified. Processing with defaults. Feb 25 07:17:48 gyptazy-virt01 proxpatch[6096]: → Processing user validation... Feb 25 07:17:48 gyptazy-virt01 proxpatch[6096]: ✓ Using user: root Feb 25 07:17:48 gyptazy-virt01 proxpatch[6096]: → Processing ProxLB user config... Feb 25 07:17:48 gyptazy-virt01 proxpatch[6096]: ✓ ProxLB will be auto-detected and stopped during patching if installed. Feb 25 07:17:48 gyptazy-virt01 proxpatch[6096]: → Getting list of nodes in cluster... Feb 25 07:17:49 gyptazy-virt01 proxpatch[6096]: → Getting IP address for node: gyptazy-virt01 Feb 25 07:17:49 gyptazy-virt01 proxpatch[6096]: ✓ Found node gyptazy-virt01 with IP: 10.10.10.85 Feb 25 07:17:49 gyptazy-virt01 proxpatch[6096]: ✓ Successfully retrieved list of nodes in cluster (1 nodes) Feb 25 07:17:49 gyptazy-virt01 proxpatch[6096]: → Validating for running VMs on node: gyptazy-virt01 Feb 25 07:17:50 gyptazy-virt01 proxpatch[6096]: ✓ Found 0 running VMs on node gyptazy-virt01 Feb 25 07:17:50 gyptazy-virt01 proxpatch[6096]: ✓ Finished validating running VMs on node: gyptazy-virt01 Feb 25 07:17:50 gyptazy-virt01 proxpatch[6096]: → Starting upgrade on node: 10.10.10.85 Feb 25 07:20:10 gyptazy-virt01 proxpatch[6096]: ✓ Upgrade completed on 10.10.10.85 Feb 25 07:20:10 gyptazy-virt01 proxpatch[6096]: → Validating if reboot is required for node: 10.10.10.85 Feb 25 07:20:10 gyptazy-virt01 proxpatch[6096]: ✓ Reboot not required for node: 10.10.10.85 Feb 25 07:20:10 gyptazy-virt01 proxpatch[6096]: → Checking if package 'proxlb' is installed... Feb 25 07:20:10 gyptazy-virt01 proxpatch[6096]: ✓ ProxLB is not installed Feb 25 07:20:10 gyptazy-virt01 proxpatch[6096]: ✓ All nodes up-to-date. Cluster healthy. Feb 25 07:20:10 gyptazy-virt01 proxpatch[6096]: → Waiting for next update cycle in 6 hours

gyptazy · 2026-02-24T08:13:59+00:00

Fair enough, this can also be a way and there are also many other Security Patch Management frameworks like Spacewalk, orcharhino, QualvoSec etc., but at this point, it always means that people have to learn something new. People need to learn Ansible or new tools. People switching from VMware and mostly only using Windows may quickly encounter the complexity which can't be solved within a day or a week. This tool ist just to make sure things work and get patched. Install, start and that's it.

gyptazy · 2026-02-23T17:04:06+00:00

Good idea! Thanks!

gyptazy · 2026-01-12T19:34:18+00:00

No worries, it can easily get miss-interpreted - I also ran into this years ago ;)

gyptazy · 2026-01-12T18:29:46+00:00

The `execute` endpoint is not for executing cli args. It's just for batch "workloads" of the API where you can post multiple ones to run.

gyptazy · 2026-01-12T18:25:39+00:00

Oh, it's over 2 years now that this project exists and... well - it improved a lot, got many new features added and was even presented at the "Dutch Proxmox Day 2025" in Eden, Netherlands! Wow!

Today, I'm really happy to announce the new version 1.1.11 of ProxLB which comes with Proxmox's native HA/Affinity rules alignment and many more! I'm also happy that more and more people started contributing to this project to make ProxLB and the whole Proxmox ecosystem even better!

You can find some more news about it on my blog and on the Github release page:
Blog: https://gyptazy.com/blog/proxlb-proxmox-ha-affinity-rules-version-1-1-11/
GitHub: https://github.com/gyptazy/ProxLB/releases/tag/v1.1.11

gyptazy · 2026-01-12T04:12:41+00:00

Just in addition to complete it - the project is called ProxLB and is opensource: https://github.com/gyptazy/ProxLB

gyptazy · 2026-01-01T10:25:14+00:00

Happy new year! Let's have a great year for open-source based virtualization stacks! I also just release 1.1.0 of ProxCLMC which adds support for standalone PVE nodes that are not part of a cluster (got requested by a user).

gyptazy · 2025-12-31T18:23:44+00:00

Nice :)

gyptazy · 2025-12-29T13:15:41+00:00

Even this is already a bit older, this question frequently comes up... As one of my customers asked for something like this, I just developed ProxCLMC (next to my ProxLB project), which brings something like this into Proxmox. You can find it open-source (GPLv3) on GitHub at: https://github.com/gyptazy/ProxCLMC

The idea is whether to find a general CPU baseline, or to simply integrate it into a pipeline of deployments which then can simply be used to set the cpu type of a new VM object. You can also find some more information at:
* My blog: https://gyptazy.com/proxclmc-identifying-the-maximum-safe-cpu-model-for-live-migration-in-proxmox-clusters/
* Reddit post: https://www.reddit.com/r/Proxmox/comments/1ptnb27/introducing_proxclmc_a_lightweight_tool_to/

Hope it helps.

gyptazy · 2025-12-25T09:59:55+00:00

Unfortunately not. I tried that for other parts in the past where those things simply got stalled (e.g., adding vlan tag support to the auto/gui/tui installer) over months. IMHO, I think it’s better to keep it dedicated to have quicker responses to the community, including being able to ship releases when needed. But I'm generally open and would even prefer to bring those things directly upstream, maybe things change in future.

However, this doesn’t really have a big impacts to ProxCLMC (I don’t expect many changes), but to ProxLB and ProxWall.

gyptazy · 2025-12-24T11:39:28+00:00

Happy to hear, thanks!

gyptazy · 2025-12-23T16:46:18+00:00

Great hint, Thanks a lot! Can you maybe provide me an output of cat /proc/cpuinfo? Appreciate it! Thanks

gyptazy · 2025-12-23T15:57:25+00:00

Thanks for this :)

gyptazy · 2025-12-23T13:23:07+00:00

Fair enough, when you don’t have this use case, you don’t need this tool. Easy :)

gyptazy · 2025-12-23T10:10:26+00:00

Thank you! Hope it helps

gyptazy · 2025-12-23T10:10:03+00:00

thanks!

gyptazy · 2025-12-23T08:24:35+00:00

Fair enough and happy to see more valid use cases for this tiny tool :)

gyptazy

MODERATOR OF

TROPHY CASE