On Thu, Dec 7, 2017 at 12:33 AM Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:

On Wed, Dec 6, 2017 at 5:23 PM, Paolo Margara <paolo.margara@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@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@ovirt01 251063f6-5570-4bdc-b28f-21e82aa5e185]#

Thanks,
Gianluca