[Bug] vmkfstools_clone silently drops disks that live on a different datastore than the boot disk

[ajoergensen]

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

vmkfstools_clone silently drops disks that live on a different datastore than the boot disk

Steps to Reproduce

• Source VM with 3 disks: disk1 + disk2 on datastore A, disk3 on datastore B.
• Migrate via auto/vmkfstools_clone.
• Result: Proxmox VM has only disk1 + disk2. disk3 is absent. Task completes "successfully".
• If all disks are migrated to the same datastore, they are all migrated

Expected behavior

All disks should be migrated, even if they are not on the same datastore.

Environment

• PegaProx Version: 0.9.13.1
• Installation Method: Manual
• OS: Debian 13
• Browser: Brave v1.91.175 (Chromium 149.0.7827.155)
• Behind Reverse Proxy? nginx
• UI? Both corporate and modern

Logs

Let me know what is needed

Screenshots

Checklist

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

[mkellermann97]

Thanks @ajoergensen — traced it, and you're exactly right. The vmkfstools_clone path discovers a VM's disks by listing the descriptor .vmdks in the VM's home folder on the boot disk's datastore only, so any disk that lives on a second datastore never gets enumerated — and since the copy loop only iterates what it found, the task reports "success" while disk3 simply isn't there. That's a real bug, not your config. The proper fix is to enumerate per-disk from the VM config (each disk carries its own [datastore] path) instead of globbing one folder, plus a found-vs-expected disk-count guard so it can never silently complete short again — flagged to @MrMasterbay since the V2P engine is mid-rework. Until it lands, keeping all disks on one datastore is the safe workaround, as you found. If this saved you a nasty restore, opencollective.com/pegaprox keeps the volunteer hours flowing 🙏 — Marcus

[mkellermann97]

Fixed on Testing (26ffc49), @ajoergensen — and I built a 2-datastore VM here to prove it out. The clone path now enumerates each disk from the VM's real backing path ([datastore] dir/disk.vmdk) and clones + transfers it from its OWN datastore, instead of only globbing the boot disk's folder. I also added a found-vs-expected disk-count guard, so a partial set now fails loudly instead of reporting a bogus success. Verified against a VM with the boot disk on one datastore and a data disk on another: both disks resolve now, where the old code saw only one. It rides the next release — if you can retest your 3-disk/2-datastore case once you're on it, I'd love the confirmation. Thanks for the sharp report; opencollective.com/pegaprox keeps the migration engine getting love 🙏 — Marcus

[mkellermann97]

Quick heads-up @ajoergensen — this shipped in v0.9.13.2, which just went out. The per-disk enumeration fix (26ffc49) and the found-vs-expected disk-count guard are both in it, so your 3-disk / 2-datastore case should now clone every disk from its own datastore instead of silently dropping the off-datastore one. Whenever you get a moment to update and rerun that migration, I'd love the confirmation so I can close this out — and if it still misses a disk, grab me the V2P task log and I'll dig back in. Thanks again for the sharp repro; opencollective.com/pegaprox is always open if the fix saved you a headache. — Marcus

[ajoergensen]

After updating the number of disks are seemingly detected correctly and the migration process detects the different source datastores for each disk

Unfortunately, the second disk on this VM failed:

[16:44:34] Cloning frozen base of disk 1: [PURE-VMWARE-05] myserver/myserver_1-000001.vmdk (100.0 GB)
[16:44:34] vmkfstools cloning frozen base -> _pegaprox_clone_160_1.vmdk (PID 2804091)
[16:45:54] Source: _pegaprox_clone_160_1-flat.vmdk (100.0 GB)
[16:46:25] Datastore: PURE-VMWARE-05
[16:46:37] Disk allocation failed for disk 1
[16:46:37] Reason: Rounding up size to full physical extent <100.02 GiB lvcreate 'pvestorage/vm-160-disk-1' error: Logical Volume "vm-160-disk-1" already exists in vol
[16:46:37] Storage: pvestorage | pvesm: Name Type Status Total (KiB) Used (KiB) Available (KiB) % pvestorage lvm active 10737414144 8530382848 2207031296 79.45%
[16:46:37] FAILED: Transfer/import of clone for disk 1 failed
[16:46:37] Phase: failed

(I'm not certain how to dig out the full migration log, so that's what I have for now)

[mkellermann97]

Thanks for retesting @ajoergensen — that confirms the #561 fix is doing its job: all disks enumerated and each source datastore resolved, which was the broken part. The new failure is a different beast: vm-160-disk-1 already exists means target VMID 160 already has that LV on pvestorage — almost certainly a leftover from your earlier attempt (before the fix the run would've allocated disk-0 and begun disk-1), and qm importdisk won't overwrite an existing volume. Cleanest path: migrate into a fresh/empty target VMID; or if you want to reuse 160, clear its stale disks first (detach, then lvremove pvestorage/vm-160-disk-1 and check for an orphaned disk-0) — only if you're certain 160 holds nothing you need. You've also surfaced a real gap: a failed migration leaves its partially-allocated target disks behind, so a same-VMID retry collides instead of pre-checking or cleaning up — I'm flagging that to @MrMasterbay for the V2P rework (a 'target already has disks' pre-flight guard + cleanup-on-failure). Mind running it once into a fresh VMID and sending the result? opencollective.com/pegaprox keeps the migration engine getting love 🙏 — Marcus

[ajoergensen]

That would be the logical conclusion, yes. But I am almost 100% certain that vmid had not been used prior.

In any case, I will try again tomorrow.

[ajoergensen]

The error happens consitently on the second disk, regardless of placement.

But it's not caused by a left over from earlier VMs, I have tested it twice now, and both times confirmed that no disks existed for the target VMID.

[mkellermann97]

You're right, @ajoergensen — scratch my leftover theory, you've cleanly ruled it out (fresh VMID, twice). So it's happening within the run: disk 0 imports fine, then disk 1's allocation hits vm-160-disk-1 already exists. On LVM our per-disk allocator only clears a pre-existing volume if PVE's pvesm path reports it — an orphaned LV created earlier in the same migration but not registered in PVE storage would slip past that check, and then lvcreate collides. So the real question is what creates vm-160-disk-1 during disk 0's step. Could you grab the pegaprox.log from disk 0 finishing through the disk 1 failure, plus lvs <yourstorage> right after it fails? That'll show whether the disk-1 LV appears during disk-0's transfer. I'm handing this to @MrMasterbay alongside the broader vmkfstools_clone-path rework — opencollective.com/pegaprox keeps the migration work moving. — Marcus