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