<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Dec 7, 2017 at 1:28 AM, Nir Soffer <span dir="ltr">&lt;<a href="mailto:nsoffer@redhat.com" target="_blank">nsoffer@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span class="gmail-"><div dir="ltr">On Thu, Dec 7, 2017 at 1:22 AM Gianluca Cecchi &lt;<a href="mailto:gianluca.cecchi@gmail.com" target="_blank">gianluca.cecchi@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 6, 2017 at 11:42 PM, Nir Soffer <span dir="ltr">&lt;<a href="mailto:nsoffer@redhat.com" target="_blank">nsoffer@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><span class="gmail-m_-4585136538415439876m_6038285226615943421gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br><br></div><div>BTW: I notice that the disk seems preallocated even if original qcow2 is thin... is this expected?</div><div>This obviously also impacts the time to upload (20Gb virtual disk with actual 1.2Gb occupied needs the time equivalent for full 20Gb...)</div></div></div></div></blockquote><div><br></div></span><div>We upload exactly the file you provided, there is no way we can upload 20G from 1.2G file :-)</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>But the upload process at a medium rate of 40-50MB/s has last about 9 minutes that confirms the 20Gb size</div><div>The disk at source has been created as virtio type and format qcow2 from virt-manager and then only installed a CentOS 7.2 OS with infrastructure server configuration.</div><div>Apart from qemu-img also ls:</div><div><div># ls -lhs c7lab1.qcow2 </div><div>1.3G -rw------- 1 root root 21G Dec  6 23:05 c7lab1.qcow2</div></div></div></div></div></blockquote><div><br></div></span><div>The fiile size is 21G - matching what you see. This is the size we upload.</div></div></div></blockquote><div><br></div><div>I changed the subject to better address and track the thread..</div><div>You are not convincing me...</div><div>The term &quot;file size&quot; is ambiguous in this context...</div><div><br></div><div>If I take a disk that was born on this oVirt environment itself I have this:</div><div><a href="https://drive.google.com/file/d/1Dtb69EKa8adNYiwUDs2d-plSMZIM0Bzr/view?usp=sharing">https://drive.google.com/file/d/1Dtb69EKa8adNYiwUDs2d-plSMZIM0Bzr/view?usp=sharing</a><br></div><div><br></div><div>that shows that is thin provisioned</div><div>Its id shown here:</div><div><a href="https://drive.google.com/file/d/1PvLjJVQ3JR4_6v5Da7ATac5ReEObxH-A/view?usp=sharing">https://drive.google.com/file/d/1PvLjJVQ3JR4_6v5Da7ATac5ReEObxH-A/view?usp=sharing</a><br></div><div><br></div><div>If I go and check on my exported file system I get this</div><div><br></div><div><div>[root@ovirt01 NFS_DOMAIN]# find . -name &quot;3c68d43f-0f28-4564-b557-d390a125daa6&quot;</div><div>./572eabe7-15d0-42c2-8fa9-0bd773e22e2e/images/3c68d43f-0f28-4564-b557-d390a125daa6</div><div>[root@ovirt01 NFS_DOMAIN]# ls -lsh ./572eabe7-15d0-42c2-8fa9-0bd773e22e2e/images/3c68d43f-0f28-4564-b557-d390a125daa6</div><div>total 8.6G</div><div>8.6G -rw-rw----. 1 vdsm kvm  10G Dec  7 08:42 09ad8e53-0b22-4fe3-b718-d14352b8290a</div><div>1.0M -rw-rw----. 1 vdsm kvm 1.0M May  1  2016 09ad8e53-0b22-4fe3-b718-d14352b8290a.lease</div><div>4.0K -rw-r--r--. 1 vdsm kvm  317 Jun 21 10:41 09ad8e53-0b22-4fe3-b718-d14352b8290a.meta</div><div><br></div><div>[root@ovirt01 NFS_DOMAIN]# qemu-img info ./572eabe7-15d0-42c2-8fa9-0bd773e22e2e/images/3c68d43f-0f28-4564-b557-d390a125daa6/09ad8e53-0b22-4fe3-b718-d14352b8290a</div><div>image: ./572eabe7-15d0-42c2-8fa9-0bd773e22e2e/images/3c68d43f-0f28-4564-b557-d390a125daa6/09ad8e53-0b22-4fe3-b718-d14352b8290a</div><div>file format: raw</div><div>virtual size: 10G (10737418240 bytes)</div><div>disk size: 8.5G</div><div>[root@ovirt01 NFS_DOMAIN]#</div></div><div><br></div><div>So it seems it is raw/sparse</div><div><a href="https://www.ovirt.org/documentation/admin-guide/chap-Virtual_Machine_Disks/">https://www.ovirt.org/documentation/admin-guide/chap-Virtual_Machine_Disks/</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>1.3G is the used size on the file system, we cannot upload only used blocks.</div><div>qemu-img info &quot;Disk size&quot; is not the file size the the used size, not useful </div><div>for upload.</div></div></div></blockquote><div><br></div><div>Why not? You can detect the format of source and use a similar strategy of the bugzilla I&#39;m referring (see below)</div><div>Or couldn&#39;t you use something like </div><div><br></div><div> rsync -av --sparse source target</div><div><br></div><div>if the target is NFS?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Maybe this file was crated with preallocation=full?</div></div></div></blockquote><div><br></div><div>In virt-manager there is not this logic by default.</div><div>The default format is qcow2/sparse</div><div>When you create/add a disk you can choose &quot;Select or create custom storage&quot;:</div><div><a href="https://drive.google.com/file/d/1gAwjAG5aRFC5fFgkoZXT5wINvQnov88p/view?usp=sharing">https://drive.google.com/file/d/1gAwjAG5aRFC5fFgkoZXT5wINvQnov88p/view?usp=sharing</a><br></div><div><br></div><div>And then choose a format between:</div><div>raw, qcow, qcow2, qed, vmdk, vpc, vdi</div><div><br></div><div>In my case it was the default one, so qcow2, as qemu-img correctly detects.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class="gmail-m_-4585136538415439876m_6038285226615943421gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br></div></div></div></blockquote></span></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>First message at beginning of upload:</div><div><br></div><div><div>2017-12-06 23:09:50,183+0100 INFO  (jsonrpc/4) [vdsm.api] START createVolume(sdUUID=u&#39;<wbr>572eabe7-15d0-42c2-8fa9-<wbr>0bd773e22e2e&#39;, spUUID=u&#39;00000001-0001-0001-<wbr>0001-000000000343&#39;, imgUUID=u&#39;251063f6-5570-4bdc-<wbr>b28f-21e82aa5e185&#39;, size=u&#39;22548578304&#39;, volFormat=4, preallocate=2, diskType=2, volUUID=u&#39;77aacfb3-9e67-4ad2-<wbr>96f6-242b5ba4d9e0&#39;, desc=u&#39;{&quot;DiskAlias&quot;:&quot;c7lab1&quot;,&quot;<wbr>DiskDescription&quot;:&quot;&quot;}&#39;, srcImgUUID=u&#39;00000000-0000-<wbr>0000-0000-000000000000&#39;, srcVolUUID=u&#39;00000000-0000-<wbr>0000-0000-000000000000&#39;, initialSize=None) from=192.168.1.212,56846, flow_id=18c6bd3b-76ab-45f9-<wbr>b8c7-09c727f44c91, task_id=e7cc67e6-4b61-4bb3-<wbr>81b1-6bc687ea5ee9 (api:46)</div></div><div><br></div></div></div></div></blockquote></span></div></div></blockquote><div><br></div><div>In this bugzilla, that is related to export from NFS to block:</div><div><a href="https://bugzilla.redhat.com/show_bug.cgi?id=1358717">https://bugzilla.redhat.com/show_bug.cgi?id=1358717</a><br></div><div><br></div><div>it seems to understand, from a comment of Maor, that </div><div>preallocate=2 --&gt; sparse<br></div><div><br></div><div>what are instead the possible values of volFormat and their decodification?</div><div>In my case it detects </div><div>volFormat=4,<br></div><div><br></div><div>Could it be something similar to the bugzilla above? Can it change anything if exporting with NFS 4.2 or using oVirt 4.2?</div><div><br></div><div>I think that if one has big qcow2 disk files that he/she desire to migrate into oVirt, the process could be optimized</div><div><br></div><div>Thanks,</div><div>Gianluca</div><div><br></div><div><br></div></div></div></div>