On Tue, Jun 25, 2019 at 8:39 PM Dmitry Filonov <filonov@hkl.hms.harvard.edu> wrote:
Sorry, don't have any logs from back then. That was some time ago and it was easy to fix so I didn't bother keeping logs. 
DISKTYPE and DESCRIPTION were the only two lines I had to fix to get disks imported nicely. 
If you like I can probably re-create situation by creating a VM, then unregistering it, changing the .meta file and try re-importing it back. 

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
On Tue, Jun 25, 2019 at 10:42 AM Nir Soffer <nsoffer@redhat.com> wrote:
On Tue, Jun 25, 2019 at 3:15 PM Dmitry Filonov <filonov@hkl.hms.harvard.edu> wrote:
Hi Nir -

 in my case these VMs were migrated from VirtualBox to oVirt using some of the VMWare provided tool
and then virt-v2v to convert images. Here's the example of the meta file -

DOMAIN=92be9db3-eab4-47ed-9ee9-87b8616b7c8c
VOLTYPE=LEAF
CTIME=1529005629
MTIME=1529005629
IMAGE=f0d0b3b3-5a31-4c9f-b551-90586bf946a5
DISKTYPE=1
PUUID=00000000-0000-0000-0000-000000000000
LEGALITY=LEGAL
POOL_UUID=
SIZE=41943040
FORMAT=RAW
TYPE=SPARSE
DESCRIPTION=generated by virt-v2v 1.36.10rhel_7,release_6.el7_5.2,libvirt
EOF

These disks worked fine on 4.2.3.8 but I wasn't able to import them into 4.3.4.3 unless I changed DISKTYPE line manually.

Do you have engine and vdsm logs from the time you imported this vm?

Which engine version was used during the import?

Nir