11:55 a.m.
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 diskswith snapshots ...
Is there a smarter way to do it ?
Cheers
Olri