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