OK, which component on bugzilla?
On Thu, May 2, 2019 at 7:29 PM Nir Soffer <nsoffer(a)redhat.com> wrote:
On Thu, May 2, 2019 at 7:18 PM Hetz Ben Hamo <hetz(a)hetz.biz>
wrote:
>
> On Thu, May 2, 2019 at 7:15 PM Nir Soffer <nsoffer(a)redhat.com> wrote:
>
>> On Thu, May 2, 2019 at 3:59 PM Hetz Ben Hamo <hetz(a)hetz.biz> wrote:
>>
>>> Hi,
>>>
>>> I've migrated few Linux VM's from virt-manager to oVirt. Other than
the
>>> famous bug that it insist to have an ISO domain
>>>
>>
>> What is this famous bug?
>>
>
>
https://bugzilla.redhat.com/show_bug.cgi?id=1632068
>
>
>>
>>
>>> - it worked well.
>>>
>>> My problem is simple: on virt-manager, I created the virtual disks as
>>> thin provisioning. ls -l shows the full size of the QCOW2 file and du -hs
>>> shows the actual size. So far, so good.
>>>
>>
>> So the source image was qcow2 image?
>>
>
> Yes, created with virt-manager.
>
>
>>
>> After migrating those VM's to oVirt, the disks appear both in the web UI
>>> and in the meta file as "Thin Provisioning" and "sparse"
- however, digging
>>> into the directory which holds the virtual disk and running du -hs - shows
>>> it's a full size disk.
>>>
>>> Why is this happening?
>>>
>>
>> How did you import the disks?
>>
>
> Through oVirt - by adding a KVM provider according to ovirt docs.
>
> In the node it seems to use the kvm2ovirt, ssh and nc to do all the hard
> work.
>
This sounds like kvm2ovirt bug, please file a bug with all the details.
Please include the info from engine about the disk format, virtual size,
actual size, and
output of these commands:
qemu-img info /path/to/volume
ls -lhs /path/to/volume
And engine and vdsm logs showing the import process.
Nir
>
>
>>
>> Nir
>>
>