[Bug] Does not wait long enough when going into maintenance mode

[rickbaran]

Hey there! 👋 Thanks for taking the time to report this bug — we appreciate it!

Please keep in mind: PegaProx is developed and maintained entirely by volunteers in our free time. We do our best, but we can't work magic 🪄 — please be patient, we'll get to your issue as soon as we can.

Want to help keep PegaProx alive?

• ⭐ Star the project — it's free and helps a lot!
• 💖 Become a Sponsor — helps us dedicate more time to development
• 🤝 Contributing code or docs is always welcome too!

---

Describe the bug

I have been noticing that when you try to place a host into maintenance mode it can sometimes come back with error that not all vm had been evacuated but if you go check PVE GUI it shows that they have been and the host is in maintenance mode already (no PVE errors). Based on observations it seems to be if there are vm with large abouts of ram and or vm's under heavy use. Would also say that it seems to happen if there is multiple vm's on the host.

Steps to Reproduce

1. Enter maintenance mode from host card

Expected behavior

recheck to see if it all tasks completed

Environment

• PegaProx Version: 0.9.5
• Installation Method: install script
• OS: Debian 12
• Browser: chrome 146.0.7680.178
• Behind Reverse Proxy? No
• UI? Modern Layout have not tried corp for this issue

Logs

Screenshots

Checklist

• I have searched existing issues to make sure this is not a duplicate
• I am using the latest version of PegaProx

[mkellermann97]

Hey, thanks for the report. This is most likely a timeout issue during VM evacuation — when you have VMs with large amounts of RAM (or under heavy I/O), live migration takes longer than the default timeout we're waiting for. PegaProx sees the migration task as "not completed" even though Proxmox is still working on it in the background.

We already bumped the evacuation migration timeout to 1800s (30 min) in a recent update, but for really large VMs that might still not be enough. We'll look into making the timeout dynamic based on VM memory size, and also add a recheck after the initial timeout to see if PVE actually completed the migration before reporting failure.

Could you share approximately how much RAM the affected VMs have and how many VMs were on the host when this happened? That would help us calibrate the timeouts better.

Regards,
Marcus

[MrMasterbay]

No response anymore ticket will be closed.

As the timeout time can also be configured in the advanced options of the update manager.

Regards,
Nico