To be honest I am not sure if this version is safe for this kind of thing, we had a serious bug around this[1]
and it was fixed in 4.2, I am not sure it applies to your case as well, as there are multiple factors in play, so best test it first on some other disk

[1] - https://bugzilla.redhat.com/show_bug.cgi?id=1574346

On Mon, Mar 18, 2019 at 2:51 PM Alan G <alan+ovirt@griff.me.uk> wrote:
It's cold migration on 4.1.9.

So I just kill this process?

vdsm     12356 26726 21 12:01 ?        00:10:24 /usr/bin/qemu-img convert -p -t none -T none -f raw /rhev/data-center/mnt/blockSD/f8ab4c37-634b-4c01-a816-40d8eb5d0d3e/images/6f340d21-6690-4c51-8129-7d6345e80956/6e8545c4-73ff-4b45-a19e-4e902822959d -O raw /rhev/data-center/mnt/blockSD/3b308f7f-f5bd-4b1e-9fea-6f91959e2dce/images/6f340d21-6690-4c51-8129-7d6345e80956/6e8545c4-73ff-4b45-a19e-4e902822959d




---- On Mon, 18 Mar 2019 12:36:13 +0000 Benny Zlotnik <bzlotnik@redhat.com> wrote ----

is this live or cold migration? 
which version?

currently the best way (and probably the only one we have) is to kill the qemu-img convert process (if you are doing cold migration), unless there is a bug in your version, it should rollback properly

On Mon, Mar 18, 2019 at 2:10 PM Alan G <alan+ovirt@griff.me.uk> wrote:

_______________________________________________
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-leave@ovirt.org

Hi,

I accidentally triggered a storage migration for a large vdisk that will take some hours to complete. Is there a way to cleanly cancel the task, such that the vdisk will remain on the original domain?

Thanks,

Alan

_______________________________________________
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-leave@ovirt.org