Sorry for the delay. vdsm logs are huge, i'll cut when i moved storage domains and attach the logs.

Before detaching storages i've checked that all disks on these storages. After detaching in the old datacenter there were left empty storage domains with only disk of hosted-engine. Rechecked this today.

That's interesting. Where can i find meta for block storage? On NFS storage these files are located next to the disk image.

On Mon, Jun 24, 2019 at 7:47 PM Dmitry Filonov <filonov(a)hkl.hms.harvard.edu&gt; wrote: I want more info on this. We think that the only value ever used for DISKTYPE is 2. Do you have any info on how these disks were created? Maybe by some ancient version? Nir

On Tue, Jun 25, 2019 at 3:15 PM Dmitry Filonov <filonov(a)hkl.hms.harvard.edu&gt; wrote: Do you have engine and vdsm logs from the time you imported this vm? Which engine version was used during the import? Nir

On Tue, Jun 25, 2019 at 8:39 PM Dmitry Filonov <filonov(a)hkl.hms.harvard.edu&gt; wrote: Sure, reproducing it easy. But we want to support only valid value created by older version of oVirt. if such volumes actually exists in the field, the system should handle the import transparently, translating the disk type to "DATA". Are you sure the metadata was not modified outside of oVirt? Nir

Hi Nir, Trying to revive this old thread, I ran in to a similar issue. I imported a few VMs from an old VMWARE version into ovirt 4.3.3 using OVAs generated on the VMWARE side. After adjusting a bit the OVAs I was able to do the import. A year later I have tried to export those VMs from 4.3.3 to a new Hyperconverged cluster that uses oVirt 4.3.10. If I try to import a VM with only 1 disk I need to modify the DISKTYPE from 1 to DATA, and Need to add the alias on the DESCRIPTION field as it does not appear on the v5 (ovirt 4.3.10). Original settings: Disk1.- [root@ovirt1 images]# strings a88461c4-61cb-4dbc-806e-484ce6fd5b4d/247d61c6-46a1-4c48-bb2d-55f6b8743692.meta DOMAIN=523debef-f166-407d-a8d8-9cfd6d20ebb7 VOLTYPE=LEAF CTIME=1574205481 MTIME=1574205481 IMAGE=a88461c4-61cb-4dbc-806e-484ce6fd5b4d DISKTYPE=1 PUUID=00000000-0000-0000-0000-000000000000 LEGALITY=LEGAL POOL_UUID= SIZE=209715200 FORMAT=RAW TYPE=SPARSE DESCRIPTION=generated by virt-v2v 1.38.2rhel_7,release_12.el7_6.2,libvirt Disk2.- [root@ovirt1 images]# strings 75044386-90db-4c16-94ad-0f376fa7ceea/d17a4bf4-e633-4e08-aa7c-42b22a2c8769.meta CAP=268435456000 CTIME=1575689283 DESCRIPTION=generated by virt-v2v 1.38.2rhel_7,release_12.el7_6.2,libvirt DISKTYPE=1 DOMAIN=523debef-f166-407d-a8d8-9cfd6d20ebb7 FORMAT=RAW GEN=0 IMAGE=75044386-90db-4c16-94ad-0f376fa7ceea LEGALITY=LEGAL PUUID=00000000-0000-0000-0000-000000000000 TYPE=PREALLOCATED VOLTYPE=LEAF I changed DISKTYPE=1 to DISKTYPE=DATA and DESCRIPTION=DESCRIPTION=generated by virt-v2v 1.38.2rhel_7,release_12.el7_6.2,libvirt TO DESCRIPTION={"DiskAlias":"MYVM-DISK1","DiskDescription":""} and for Disk2 DESCRIPTION={"DiskAlias":"MYVM-DISK2","DiskDescription":""} VMs with only 1 disk on their configuration only migrates the disk and only able to import the disk, not the VM from an NFS sharead data domain. So I had to create the VM and attach the imported disk and worked fine. Then I tranfered the disk from the NFS domain to the VMSTORE Gluster domain... up to here all good. Problem when I tried to do the same with a VM with 2 disks, up to starting the VM all was good, however migrating the storage to the VMSTORE Gluster domain the second disk stays in migration forever, issue related to deleting auto generated snapshot of the second disk. In order to half way solve the issue I had to follow up on: https://access.redhat.com/solutions/396753 https://access.redhat.com/solutions/1347513 https://access.redhat.com/solutions/3991591 /usr/share/ovirt-engine/setup/dbutils/ https://lists.ovirt.org/pipermail/users/2016-May/039898.html but this caused a lot of downtime, so right now 1 disk of the VM is on VMSTORE DOMAIN (Gluster), and one disk on the migration data domain (NFS). Seems I can't transfer the second disk to VMSTORE Domain. Any ideas? Thanks, AQ