[ovirt-users] Re: Can't import some VMs after storage domain detach and reattach to new datacenter.

On Tue, Jun 25, 2019 at 8:39 PM Dmitry Filonov < filonov(a)hkl.hms.harvard.edu&gt; 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(a)redhat.com&gt; wrote: > >> On Tue, Jun 25, 2019 at 3:15 PM Dmitry Filonov < >> filonov(a)hkl.hms.harvard.edu&gt; 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 >> >