nagaboinaramgopal commented on issue #13390:
URL: https://github.com/apache/cloudstack/issues/13390#issuecomment-5636259106
@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:
libvirt 9.0.0 / QEMU 7.2 (Debian 12): THIN ok, FAT ok, THIN with a SCSI
root disk (sda) ok
libvirt 11.3.0 / QEMU 10.0 (Debian 13): THIN ok, FAT ok
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:
- what backs the SharedMountPoint (cluster filesystem, NFS, ...), and
whether it is mounted at the same path and is the same storage on every host
- the pool scope (cluster or zone)
- the libvirt and QEMU versions on the hosts
- the agent log on the source host around the MigrateCommand
- whether the destination volume file exists on the target pool, on the
destination host, right before it fails
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
