Hi, after upgrading cluster compatibility from V3.6 to V4.2, i found all V3.6 disks with *snapshots* QCOW V2 are not working on NFS and Export Domains. Non UI command solves this problem, all stuck, they worsen disk state to "Illegal" and produces "Async Tasks" these newer ends. It seems that the disk file on storage domain has been renamed with addition -NNNNNNNNNNNN but the QCOW backing file locations in data files are not updated. They point to old disk names. [root@ovn-monster 706ff176-4f96-42fe-a5fa-56434347f16c]# ls -la insgesamt 4983972 drwxr-xr-x. 2 vdsm kvm 4096 28. Feb 12:57 . drwxr-xr-x. 64 vdsm kvm 4096 1. Mär 12:02 .. -rw-rw----. 1 vdsm kvm 53687091200 5. Sep 2016 239c0ffc-8249-4d08-967a-619abbbb897a -rw-rw----. 1 vdsm kvm 1048576 5. Sep 2016 239c0ffc-8249-4d08-967a-619abbbb897a.lease -rw-r--r--. 1 vdsm kvm 319 5. Sep 2016 239c0ffc-8249-4d08-967a-619abbbb897a.meta -rw-rw----. 1 vdsm kvm 966393856 6. Sep 2016 2f773536-9b60-4f53-b179-dbf64d182a41 -rw-rw----. 1 vdsm kvm 1048576 5. Sep 2016 2f773536-9b60-4f53-b179-dbf64d182a41.lease -rw-r--r--. 1 vdsm kvm 264 6. Sep 2016 2f773536-9b60-4f53-b179-dbf64d182a41.meta -rw-rw----. 1 vdsm kvm 2155806720 14. Feb 11:53 67f96ffc-3a4f-4f3d-9c1b-46293e0be762 -rw-rw----. 1 vdsm kvm 1048576 6. Sep 2016 67f96ffc-3a4f-4f3d-9c1b-46293e0be762.lease -rw-r--r--. 1 vdsm kvm 260 6. Sep 2016 67f96ffc-3a4f-4f3d-9c1b-46293e0be762.meta [root@ovn-monster 706ff176-4f96-42fe-a5fa-56434347f16c]# file * 239c0ffc-8249-4d08-967a-619abbbb897a: x86 boot sector; partition 1: ID=0x83, starthead 32, startsector 2048, 104853504 sectors, code offset 0xb8 239c0ffc-8249-4d08-967a-619abbbb897a.lease: data 239c0ffc-8249-4d08-967a-619abbbb897a.meta: ASCII text 2f773536-9b60-4f53-b179-dbf64d182a41: QEMU QCOW Image (v2), has backing file (path ../706ff176-4f96-42fe-a5fa-56434347f16c/239c0ffc-8249-4d08-967a), 53687091200 bytes 2f773536-9b60-4f53-b179-dbf64d182a41.lease: data 2f773536-9b60-4f53-b179-dbf64d182a41.meta: ASCII text 67f96ffc-3a4f-4f3d-9c1b-46293e0be762: QEMU QCOW Image (v2), has backing file (path ../706ff176-4f96-42fe-a5fa-56434347f16c/2f773536-9b60-4f53-b179), 53687091200 bytes 67f96ffc-3a4f-4f3d-9c1b-46293e0be762.lease: data 67f96ffc-3a4f-4f3d-9c1b-46293e0be762.meta: ASCII text My solution is, to hard-link the disk files to old names too. Then the disk could be handled by UI again. [root@ovn-monster 706ff176-4f96-42fe-a5fa-56434347f16c]# ln 239c0ffc-8249-4d08-967a-619abbbb897a 239c0ffc-8249-4d08-967a [root@ovn-monster 706ff176-4f96-42fe-a5fa-56434347f16c]# ln 2f773536-9b60-4f53-b179-dbf64d182a41 2f773536-9b60-4f53-b179 To fix the illegal disk state, i manipulate the postgres database directly, thanx to ovirt-users mailing list. Rescan of DIsks in the UI could also work, i will test it in the evening, i have a lot of old exported disks with snapshots ... Is there a smarter way to do it ? Cheers! Olri