On Tue, Jun 25, 2019 at 8:39 PM Dmitry Filonov <filonov(a)hkl.hms.harvard.edu>
Sorry, don't have any logs from back then. That was some time ago
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
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.
volumes actually exists in the field, the system should handle the import
translating the disk type to "DATA".
Are you sure the metadata was not modified outside of oVirt?
On Tue, Jun 25, 2019 at 10:42 AM Nir Soffer
> On Tue, Jun 25, 2019 at 3:15 PM Dmitry Filonov <
> filonov(a)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
>> DESCRIPTION=generated by virt-v2v 1.36.10rhel_7,release_6.el7_5.2,libvirt
>> These disks worked fine on 220.127.116.11 but I wasn't able to import them into
>> 18.104.22.168 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?