What were you trying to do that didn't work?

Cancel migration attempt while maintaining data integrity of the image.

What is the impact of this issue to you?

Not sure, it seems qemu-img check -r can be used to fix cluster issues
It's a robustess test case that fails due to this

Please provide the package NVR for which the bug is seen:

qemu-kvm-10.1.0-10.el9.s390x
kernel-5.14.0-654.el9.s390x

How reproducible is this bug?:

9/10

Steps to reproduce

1. Prepare a shared nfs folder between two hosts
2. Start VM
3. Identify qemu process of the VM
4. Start the live migration e.g.

   virsh -c 'qemu:///system' migrate --live --p2p --verbose --domain avocado-vt-vm1 --desturi qemu+tcp://10.0.160.10/system --bandwidth 100

5. While the Migration is executing, kill the qemu process on source host with ``kill -9``
6. Check the image with

   qemu-img check

Expected results

Command returns with exit code 0

Actual results

Command returns with exit code 3 (leaked cluster)

# qemu-img check /var/lib/libvirt/migrate/jeos-27-s390x.qcow2
Leaked cluster 26353 refcount=1 reference=0

1 leaked clusters were found on the image.
This means waste of disk space, but no harm to data.
47166/163840 = 28.79% allocated, 76.92% fragmented, 73.72% compressed clusters
Image end offset: 1727201280

Additional information

1. This does not seem to happen on x86_64, I checked 4/4 recent executions passed, test destructive_operations_around_live_migration.kill_qemu_during_performphase.kill_src_qemu.with_precopy.
2. This was never tested before AFAIK so don't know if regression issue at this point.
3. Set Severity to Moderate for root causing but assume no data issue "This means waste of disk space, but no harm to data."