Repository navigation
VM live migrate with storage fails on SharedMountPoint target with "pre-creation of storage target for incremental storage migration is not supported" #13390
Description
problem
Live migrating a VM with storage to a SharedMountPoint target pool fails with:
LibvirtException: Operation not supported: pre-creation of storage target for incremental storage migration of disk 'sda' is not supported
The failure affects both THIN and FAT provisioned volumes on SharedMountPoint destinations, caused by two separate bugs in StorageSystemDataMotionStrategy:
Bug 1: getVolumeBackingFile incorrectly returns non-null for FAT provisioned volumes
getVolumeBackingFile() determines whether a volume has a QCOW2 backing chain by looking up the template in template_spool_ref, not by inspecting the actual disk. For FAT provisioned volumes, template_id is still set in the volumes table and the template is still registered in template_spool_ref, so the method returns the template's install path even though the actual QCOW2 disk on disk has no backing file at all. This causes FAT volumes to be incorrectly classified as linked clones.
Bug 2: decideMigrationTypeAndCopyTemplateIfNeeded treats SharedMountPoint the same as NFS
supportStoragePoolType() always includes SharedMountPoint in its accepted types alongside NetworkFilesystem. So any volume with a non-null srcVolumeBackingFile (THIN) destined for a SharedMountPoint pool is routed to LinkedClone migration. This sets the libvirt flag VIR_MIGRATE_NON_SHARED_INC (128), which requires QEMU to pre-create the destination disk with a backing chain. QEMU does not support this pre-creation step on SharedMountPoint storage, causing the migration to fail. NFS works because QEMU can freely create QCOW2 files with backing chains on a flat filesystem.
Together, both bugs result in migrateNonSharedInc = true for all volume types on SharedMountPoint destinations, always triggering the libvirt failure.
The bug does not trigger if template_id is set to null in the volumes table, because getVolumeBackingFile() returns null in that case, causing the code to fall through to FullClone which uses VIR_MIGRATE_NON_SHARED_DISK (64) — a flag QEMU supports on SharedMountPoint storage.
versions
4.22.0/4.22.1
The steps to reproduce the bug
- Set up a CloudStack KVM environment with a SharedMountPoint primary storage pool.
- Deploy a VM from a standard template — reproduce with both THIN and FAT provisioned disk offerings.
- Add a second SharedMountPoint primary storage pool as the migration target.
- Trigger a live migration of the VM with storage to the target pool (migrateVirtualMachineWithVolume).
- Observe the migration fails with the error above for both THIN and FAT provisioned volumes.
Workaround: Set template_id = NULL in the volumes table for the affected volumes before migrating. This forces FullClone migration and avoids the libvirt flag.
What to do about it?
Two 1-line fixes, both in StorageSystemDataMotionStrategy.java:
Fix 1: getVolumeBackingFile: skip FAT volumes (covers FAT on all storage types)
if (srcVolumeInfo.getHypervisorType() == HypervisorType.KVM &&
srcVolumeInfo.getTemplateId() != null && srcVolumeInfo.getPoolId() != null &&
+ srcVolumeInfo.getProvisioningType() != Storage.ProvisioningType.FAT) {
Fix 2: decideMigrationTypeAndCopyTemplateIfNeeded: exclude SharedMountPoint (covers THIN on SharedMountPoint)
if (StringUtils.isNotBlank(srcVolumeBackingFile) &&
supportStoragePoolType(destStoragePool.getPoolType(), StoragePoolType.Filesystem) &&
+ destStoragePool.getPoolType() != StoragePoolType.SharedMountPoint &&
srcVolumeInfo.getTemplateId() != null &&
Objects.nonNull(vmTemplate) &&
!Arrays.asList(KVM_VM_IMPORT_DEFAULT_TEMPLATE_NAME, VM_IMPORT_DEFAULT_TEMPLATE_NAME)
.contains(vmTemplate.getName())) {
Both fixes force the affected paths to return FullClone → VIR_MIGRATE_NON_SHARED_DISK, which QEMU supports on SharedMountPoint storage. The template pre-copy step is also correctly skipped in both cases.
Activity
github-actions commentedon Aug 19, 2026
🎯 Triage report
Live migration of a VM with storage to a SharedMountPoint target pool fails for both THIN and FAT provisioned volumes with a libvirt error about unsupported pre-creation of a storage target for incremental migration. The reporter root-caused this to two specific bugs in
StorageSystemDataMotionStrategyand included exact proposed one-line fixes with a documented workaround (nullingtemplate_id).📊 Assessment
StorageSystemDataMotionStrategy) and SharedMountPoint pool type are storage/KVM concerns.StorageSystemDataMotionStrategy.java; well-scoped for direct implementation and testing against the reported repro steps.💡 Notes and suggestions
getVolumeBackingFile's linked-clone detection, and excluding SharedMountPoint from the NFS-like linked-clone path) — these should be reviewed and tested against both THIN and FAT SharedMountPoint migration scenarios, plus regression-tested against existing NFS-based live migration to ensure no behavior change there.Add this agentic workflows to your repo
To install this agentic workflow, run
rootnomad commentedon Sep 11, 2026
@prashanthr2
I tried to reproduce this with migrateVirtualMachineWithVolume between two SharedMountPoint pools (NFS mounted at the same path on every host, cluster scope) on 4.23 (main), where the SharedMountPoint code in StorageSystemDataMotionStrategy and KvmNonManagedStorageDataMotionStrategy is the same as 4.22 apart from CLVM changes. It worked every time:
Before the MigrateCommand, the management server copies the template to the target pool and sends a CreateObjectCommand that creates the destination volume, so libvirt finds the target disk and does not need to pre-create it. The error you see is what libvirt reports when the target disk does not exist on the destination host during an incremental migration, so something in the environment keeps that file from being there.
Could you share:
Separately, I can confirm the FAT part of bug 1: after migration the FAT volume ends up as a qcow2 with the template as its backing file on the target pool, even though the source volume had none, because getVolumeBackingFile only checks template_spool_ref. It did not fail here, but it does change the volume layout.