[Feature] Like #130 - Automatically evacuate CTs with local disk for rolling updates (using --with-local-disk)

[xrcam]

Got an idea? Nice! 💡 We love hearing what features would make PegaProx better for you.

A friendly reminder: PegaProx is built by volunteers in our spare time. We can't promise timelines or guarantee every feature will be implemented — but every suggestion helps shape the roadmap!

Want to help move things faster?

• 💖 Become a Sponsor — sponsored features get prioritized
• ⭐ Star the project — helps with visibility
• 🤝 Even better: submit a PR with your idea!

---

Describe the feature

Have CTs with local disks autatically evacuated whith rolling upgrades. Same functionnality as feature #130 but for CTs.

Use Case

That will let PegaProx takes care of all the migration needed for rollgin upgrades.

Alternatives considered

Manually migrate CTs.

How important is this for you?

It will saves me time and let PegaProx doins all the jobs (almost there).

Checklist

Related to #130. My Cts are already replicated on each nodes (local disks) every four (4) hours.

[mkellermann97]

Hey @xrcam — correcting myself, my earlier reply on this thread was wrong on the upstream-Proxmox part. Looked at our code and the Proxmox docs again:

• LXC has no live migration. That's a technical limitation of LXC itself, not something Proxmox is going to add — quoting the Proxmox forum thread on it: "running containers cannot be live-migrated due to technical limitations". Sub-second restart-migration is the supported path.
• For local-disk CTs, Proxmox already provides what's needed: pct migrate <vmid> <target> --restart --target-storage <map> — stops the CT, rsyncs the disk, starts on the target. PVE docs note this typically results in "some hundreds of milliseconds" of downtime.
• PegaProx already uses exactly that path in the rolling-update / evacuation code (manager.py LXC branch with restart=1 + target-storage mapping), and the evacuation loop iterates both qemu and lxc. The Allow --with-local-disks migration toggle introduced in [Feature] Add vm migration --with-local-disks option for rolling updates #330 also covers containers.

So this should already work for you in v0.9.8.2 — when you trigger maintenance / rolling update on a node, enable the Allow --with-local-disks migration toggle and CTs with local disks are evacuated alongside the VMs.

The toggle wording was the misleading part — it only mentioned "VMs" so the CT side wasn't visible. We're updating the label and tooltip to read "Migrate VMs and Containers with local disks" with a note that VMs migrate live and CTs use restart-migration with sub-second downtime. That'll go out in the next release.

Closing this since the underlying functionality already ships. If your CTs aren't actually getting evacuated when the toggle is on, please reopen and we'll dig in.

— Marcus