[Bug] fix custom args breaks cross-cluster-migration

[proxforge]

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

when you use "fix custom args" via rightclick on a vm in enterprise view it sets custom args in the vms.conf - but those vms cant be livemigrated anymore.

Steps to Reproduce

1. use "fix custom args"
2. try to cross cluster migrate a vm
3. get a error

Expected behavior

Warn on "custom args" usage (not even sure why this feature is here? Is this "fix" really needed? my vm got "rgs: -set device.scsi0.logical_block_size=512 -set device.scsi0.physical_block_size=512" as I clicked on it (which btw did not give me any information that it "did" something).

Environment

• PegaProx Version: PegaProx Beta 0.9.10.2
• Installation Method: script vom website
• OS: debian13
• Browser: Firefox
• Behind Reverse Proxy? no
• UI? corporate

Logs

args: -set device.scsi0.logical_block_size=512 -set device.scsi0.physical_block_size=512
boot: order=scsi0;net0
cores: 2
cpu: x86-64-v2-AES
memory: 8192
meta: creation-qemu=9.0.2,ctime=1738655095
name: js-pdm-01
net0: virtio=BC:24:11:C3:62:8E,bridge=vmbr0,firewall=1
numa: 0
onboot: 1
ostype: l26
scsi0: vm_nvme:vm-102-disk-0,discard=on,iothread=1,size=32G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=51f38648-973e-4965-8496-672af9662503
sockets: 1
vmgenid: 553312f0-2b39-47df-bcc8-9689d1d15790

Header
Proxmox
Virtual Environment 9.1.9
Node 'training3'
Logs
()
2026-05-17 15:31:33 conntrack state migration not supported or disabled, active connections might get dropped
2026-05-17 15:31:33 remote: started tunnel worker 'UPID:training4:0000315F:00020EB8:6A09C335:qmtunnel:102:root@pam!pegaprox-migrate-1779024693:'
tunnel: -> sending command "version" to remote
tunnel: <- got reply
2026-05-17 15:31:33 local WS tunnel version: 2
2026-05-17 15:31:33 remote WS tunnel version: 2
2026-05-17 15:31:33 minimum required WS tunnel version: 2
websocket tunnel started
2026-05-17 15:31:33 starting migration of VM 102 to node 'training4' (192.168.178.14)
tunnel: -> sending command "bwlimit" to remote
tunnel: <- got reply
2026-05-17 15:31:33 found local disk 'vm_nvme:vm-102-disk-0' (attached)
2026-05-17 15:31:33 mapped: net0 from vmbr0 to vmbr0
2026-05-17 15:31:33 Allocating volume for drive 'scsi0' on remote storage 'local-zfs'..
tunnel: -> sending command "disk" to remote
tunnel: <- got reply
2026-05-17 15:31:34 volume 'vm_nvme:vm-102-disk-0' is 'local-zfs:vm-102-disk-0' on the target
tunnel: -> sending command "config" to remote
tunnel: <- got reply
2026-05-17 15:31:34 ERROR: error - tunnel command '{"firewall-config":null,"conf":"args: -set device.scsi0.logical_block_size=512 -set device.scsi0.physical_block_size=512\nboot: order=scsi0;net0\ncores: 2\ncpu: x86-64-v2-AES\nlock: migrate\nmemory: 8192\nmeta: creation-qemu=9.0.2,ctime=1738655095\nname: js-pdm-01\nnet0: virtio=BC:24:11:C3:62:8E,bridge=vmbr0,firewall=1\nnuma: 0\nonboot: 1\nostype: l26\nscsi0: local-zfs:vm-102-disk-0,discard=on,format=raw,iothread=1,size=32G,ssd=1\nscsihw: virtio-scsi-single\nsmbios1: uuid=51f38648-973e-4965-8496-672af9662503\nsockets: 1\nvmgenid: 553312f0-2b39-47df-bcc8-9689d1d15790\n","cmd":"config"}' failed - failed to handle 'config' command - only root can set 'args' config
2026-05-17 15:31:34 aborting phase 1 - cleanup resources
tunnel: -> sending command "quit" to remote
tunnel: <- got reply
2026-05-17 15:31:35 ERROR: migration aborted (duration 00:00:02): error - tunnel command '{"firewall-config":null,"conf":"args: -set device.scsi0.logical_block_size=512 -set device.scsi0.physical_block_size=512\nboot: order=scsi0;net0\ncores: 2\ncpu: x86-64-v2-AES\nlock: migrate\nmemory: 8192\nmeta: creation-qemu=9.0.2,ctime=1738655095\nname: js-pdm-01\nnet0: virtio=BC:24:11:C3:62:8E,bridge=vmbr0,firewall=1\nnuma: 0\nonboot: 1\nostype: l26\nscsi0: local-zfs:vm-102-disk-0,discard=on,format=raw,iothread=1,size=32G,ssd=1\nscsihw: virtio-scsi-single\nsmbios1: uuid=51f38648-973e-4965-8496-672af9662503\nsockets: 1\nvmgenid: 553312f0-2b39-47df-bcc8-9689d1d15790\n","cmd":"config"}' failed - failed to handle 'config' command - only root can set 'args' config
TASK ERROR: migration aborted

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 @proxforge — thanks for filing. You hit two separate but related problems here, both legit.

Context on the "Fix QEMU args" action: it was added in April as a recovery path for V2P-migrated VMs whose target LUN had 4K logical sectors. When that happens the guest GPT (written for 512b) reads wrong → INACCESSIBLE_BOOT_DEVICE. The fix injects -set device.<bus><N>.logical_block_size=512 ... into the VM's args field so QEMU emulates 512b regardless of what the LUN reports. v2p applies this automatically during migration prep; the right-click action is a "re-apply" path for when the operator later changes the disk bus (scsi0 → sata0) and the static device-name refs in the existing args break.

What it should NOT be: a thing you click on a healthy VM that doesn't need it. Two real bugs in your report:

1. No confirmation / warning before applying. The action currently runs immediately on click with no "are you sure" prompt explaining what it does. That's the UX gap you hit — at minimum we need a modal that says "this sets args: on the VM config, which may interfere with live-migration; only use after a disk-bus change on a V2P-migrated VM" with a confirm button.
2. No success toast in your case. The frontend code at dashboard.js:12515-12526 does try to show one (data.message || 'args updated'), but the actual addToast call on success is hooked to data.changed ? 'success' : 'info' — possible the backend returned without a message field, possible something else. Worth tracing.

And the migration-break itself: args: field on the source VM doesn't always transfer cleanly through PVE's cross-cluster tunnel — that's a known PVE limitation (the args reference specific device IDs that may not match on the target). Two ways to address that on our side: either strip auto-injected sector-emulation args before kicking off cross-cluster migration, or warn the user that the VM has args set and migration may fail.

Not shipping a fix in v0.9.10.3 (just released this morning) since this needs UI + possibly backend changes. Leaving open as a tracked bug — next release wave will pick it up. If you have a workaround need right now: edit the VM in PVE directly with qm set <vmid> --delete args to clear it, then migrate, then re-apply via the PegaProx action if you actually need the sector emulation back.

Donations at https://opencollective.com/pegaprox if surfacing these kinds of multi-layer UX issues earns its keep.

— Marcus