[ovirt-users] how to setup image-io-proxy after initially disabling it
Nir Soffer
nsoffer at redhat.com
Wed Dec 6 22:42:30 UTC 2017
On Thu, Dec 7, 2017 at 12:33 AM Gianluca Cecchi <gianluca.cecchi at gmail.com>
wrote:
> On Wed, Dec 6, 2017 at 5:23 PM, Paolo Margara <paolo.margara at polito.it>
> wrote:
>
>> I think that it could be useful.
>>
>>
>> Greetings,
>>
>> Paolo
>>
>
> +1
>
> BTW: I notice that the disk seems preallocated even if original qcow2 is
> thin... is this expected?
> This obviously also impacts the time to upload (20Gb virtual disk with
> actual 1.2Gb occupied needs the time equivalent for full 20Gb...)
>
We upload exactly the file you provided, there is no way we can upload 20G
from 1.2G file :-)
But maybe we created the file in the wrong format?
Can you share vdsm logs from the spm, showing how the disk was created?
>
> On source (created from virt-manager in Fedora 26):
>
> # qemu-img info c7lab1.qcow2
> image: c7lab1.qcow2
> file format: qcow2
> virtual size: 20G (21474836480 bytes)
> disk size: 1.2G
> cluster_size: 65536
> Format specific information:
> compat: 1.1
> lazy refcounts: true
> refcount bits: 16
> corrupt: false
>
> After uploading on NFS storage domain:
>
NFS version?
>
> [root at ovirt01 251063f6-5570-4bdc-b28f-21e82aa5e185]# qemu-img info
> 77aacfb3-9e67-4ad2-96f6-242b5ba4d9e0
> image: 77aacfb3-9e67-4ad2-96f6-242b5ba4d9e0
> file format: qcow2
> virtual size: 20G (21474836480 bytes)
> disk size: 20G
> cluster_size: 65536
> Format specific information:
> compat: 1.1
> lazy refcounts: true
> refcount bits: 16
> corrupt: false
> [root at ovirt01 251063f6-5570-4bdc-b28f-21e82aa5e185]#
>
> Thanks,
> Gianluca
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20171206/e932e962/attachment.html>
More information about the Users
mailing list