<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Dec 7, 2017 at 10:15 AM Gianluca Cecchi <<a href="mailto:gianluca.cecchi@gmail.com">gianluca.cecchi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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"><<a href="mailto:nsoffer@redhat.com" target="_blank">nsoffer@redhat.com</a>></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="m_7852077843845260491gmail-"><div dir="ltr">On Thu, Dec 7, 2017 at 1:22 AM Gianluca Cecchi <<a href="mailto:gianluca.cecchi@gmail.com" target="_blank">gianluca.cecchi@gmail.com</a>> 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"><<a href="mailto:nsoffer@redhat.com" target="_blank">nsoffer@redhat.com</a>></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="m_7852077843845260491gmail-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></div></div></blockquote><div><br></div><div>Trying harder...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The term "file size" is ambiguous in this context...</div></div></div></div></blockquote><div><br></div><div>It is not. file size is what you get from stat:</div><div><br></div><div><div>$ truncate -s 1g empty<br></div><div><br></div><div>$ stat empty </div><div> File: 'empty'</div><div> Size: 1073741824<span style="white-space:pre"> </span>Blocks: 0 IO Block: 4096 regular file</div><div> ...</div><div><br></div><div>$ qemu-img info empty</div><div>image: empty</div><div>file format: raw</div><div>virtual size: 1.0G (1073741824 bytes)</div><div>disk size: 0</div></div><div><br></div><div>The value "disk size" used by qemu-img is confusing and not useful</div><div>when you want to transfer the file to another host.</div><div><br></div><div>I don't know why qemu-img display this value instead of the actual</div><div>file size, adding qemu-block mailing list in case someone can explain</div><div>this.</div><div><br></div><div>When you upload or download this file, you will transfer 1g of zeros.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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" target="_blank">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" target="_blank">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 "3c68d43f-0f28-4564-b557-d390a125daa6"</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/" target="_blank">https://www.ovirt.org/documentation/admin-guide/chap-Virtual_Machine_Disks/</a></div></div></div></div></blockquote><div><br></div><div>Yes this is raw sparse file.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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"><div>1.3G is the used size on the file system, we cannot upload only used blocks.</div><div>qemu-img info "Disk size" 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'm referring (see below)</div><div>Or couldn't you use something like </div></div></div></div></blockquote><div><br></div><div>That bug is not related. It was about converting raw sparse format</div><div>to qcow2.</div><div><br></div><div>In 4.2 we use qemu-img map and the same algorithm used in qemu to </div><div>estimate the required size needed to convert raw volume to qcow2 volume.</div><div><br></div><div>For transferring images over http, there is no way to avoid sending </div><div>unused blocks, except compression.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div> rsync -av --sparse source target</div></div></div></div></blockquote><div><br></div><div>You can use rsync to transfer images if you like, but we support</div><div>only http.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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 "Select or create custom storage":</div><div><a href="https://drive.google.com/file/d/1gAwjAG5aRFC5fFgkoZXT5wINvQnov88p/view?usp=sharing" target="_blank">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></div></div></blockquote><div><br></div><div>I tested creating qcow2 files with virt manager, and it seems to use</div><div>the preallocation=metadata by default (behind your back), I guess </div><div>for improving performance in some cases. oVirt doe not use this</div><div>option so we don't have this issue when downloading files.</div><div><br></div><div>Here example of image created by virt-manager:</div><div><br></div><div><div># ls -lsh fedora26-2.img </div><div>3.4M -rw-------. 1 root root 21G Dec 7 21:36 fedora26-2.img</div><div><br></div><div># qemu-img info fedora26-2.img </div><div>image: fedora26-2.img</div><div>file format: qcow2</div><div>virtual size: 20G (21474836480 bytes)</div><div>disk size: 3.3M</div><div>cluster_size: 65536</div><div>Format specific information:</div><div> compat: 1.1</div><div> lazy refcounts: true</div><div> refcount bits: 16</div><div> corrupt: false</div></div><div><br></div><div>And here is same image as ovirt create images:</div><div><br></div><div><div># qemu-img create -f qcow2 test.qcow2 20g</div><div>Formatting 'test.qcow2', fmt=qcow2 size=21474836480 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16</div><div><br></div><div># qemu-img info test.qcow2 </div><div>image: test.qcow2</div><div>file format: qcow2</div><div>virtual size: 20G (21474836480 bytes)</div><div>disk size: 196K</div><div>cluster_size: 65536</div><div>Format specific information:</div><div> compat: 1.1</div><div> lazy refcounts: false</div><div> refcount bits: 16</div><div> corrupt: false</div><div><br></div><div># ls -lhs test.qcow2 </div><div>196K -rw-r--r--. 1 root root 193K Dec 7 21:40 test.qcow2</div></div><div><br></div><div>So to download this image you need to transfer only 196k of data, not 20g.</div><div><br></div><div>We can get the same results as virt-manager if we use preallocation=metadata:</div><div> </div><div><div># qemu-img create -f qcow2 -o preallocation=metadata test-preallocation-metadata.qcow2 20g</div><div>Formatting 'test-preallocation-metadata.qcow2', fmt=qcow2 size=21474836480 encryption=off cluster_size=65536 preallocation=metadata lazy_refcounts=off refcount_bits=16</div><div><br></div><div># qemu-img info test-preallocation-metadata.qcow2 </div><div>image: test-preallocation-metadata.qcow2</div><div>file format: qcow2</div><div>virtual size: 20G (21474836480 bytes)</div><div>disk size: 3.3M</div><div>cluster_size: 65536</div><div>Format specific information:</div><div> compat: 1.1</div><div> lazy refcounts: false</div><div> refcount bits: 16</div><div> corrupt: false</div><div><br></div><div># ls -lhs test-preallocation-metadata.qcow2 </div><div>3.4M -rw-r--r--. 1 root root 21G Dec 7 21:42 test-preallocation-metadata.qcow2</div></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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="m_7852077843845260491gmail-"><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>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'572eabe7-15d0-42c2-8fa9-0bd773e22e2e', spUUID=u'00000001-0001-0001-0001-000000000343', imgUUID=u'251063f6-5570-4bdc-b28f-21e82aa5e185', size=u'22548578304', volFormat=4, preallocate=2, diskType=2, volUUID=u'77aacfb3-9e67-4ad2-96f6-242b5ba4d9e0', desc=u'{"DiskAlias":"c7lab1","DiskDescription":""}', srcImgUUID=u'00000000-0000-0000-0000-000000000000', srcVolUUID=u'00000000-0000-0000-0000-000000000000', initialSize=None) from=192.168.1.212,56846, flow_id=18c6bd3b-76ab-45f9-b8c7-09c727f44c91, task_id=e7cc67e6-4b61-4bb3-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" target="_blank">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 --> 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></div></div></blockquote><div><br></div><div>To optimize the import of images with unneeded preallocation, you can</div><div>convert them to unallocated and compressed images as I showed</div><div>in the previous mail.</div><div><br></div><div>Here is an example with the preallocated images, like the one from virt-manager.</div><div><br></div><div>I'll create file with some data - I'm using data that will compress well</div><div>to make the example more convincing :-)</div><div><br></div><div><div># dd if=/dev/zero bs=8M count=128 | tr "\0" "\1" > image.raw</div><div>128+0 records in</div><div>128+0 records out</div><div>1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.88171 s, 571 MB/s</div></div><div><br></div><div>Add some empty space:<br></div><div><br></div><div><div># truncate -s 10g image.raw </div><div><br></div><div><div># ls -lhs image.raw </div><div>1.1G -rw-r--r--. 1 root root 10G Dec 7 22:01 image.raw</div></div></div><div><br></div><div>Now lest create a qcow2 preallocated image like virt-manger does:</div><div><br></div><div><div># qemu-img convert -f raw -O qcow2 -o preallocation=metadata image.raw image-preallocated-metadata.qcow2</div><div><br></div><div># qemu-img info image-preallocated-metadata.qcow2 </div><div>image: image-preallocated-metadata.qcow2</div><div>file format: qcow2</div><div>virtual size: 10G (10737418240 bytes)</div><div>disk size: 1.0G</div><div>cluster_size: 65536</div><div>Format specific information:</div><div> compat: 1.1</div><div> lazy refcounts: false</div><div> refcount bits: 16</div><div> corrupt: false</div></div><div><br></div><div><div># ls -lhs image*</div><div>1.1G -rw-r--r--. 1 root root 11G Dec 7 22:02 image-preallocated-metadata.qcow2</div><div>1.1G -rw-r--r--. 1 root root 10G Dec 7 22:01 image.raw</div></div><div><br></div><div>Finally, create a compressed qcow2, optimized for upload:</div><div><br></div><div># qemu-img convert -c -f qcow2 -O qcow2 image-preallocated-metadata.qcow2 image-preallocated-metadata-optimized.qcow2 <br></div><div><br></div><div><div># qemu-img info image-preallocated-metadata-optimized.qcow2 </div><div>image: image-preallocated-metadata-optimized.qcow2</div><div>file format: qcow2</div><div>virtual size: 10G (10737418240 bytes)</div><div>disk size: 1.6M</div><div>cluster_size: 65536</div><div>Format specific information:</div><div> compat: 1.1</div><div> lazy refcounts: false</div><div> refcount bits: 16</div><div> corrupt: false</div></div><div><br></div><div><div># ls -lhs image*</div><div>1.6M -rw-r--r--. 1 root root 1.7M Dec 7 22:04 image-preallocated-metadata-optimized.qcow2</div><div>1.1G -rw-r--r--. 1 root root 11G Dec 7 22:02 image-preallocated-metadata.qcow2</div><div>1.1G -rw-r--r--. 1 root root 10G Dec 7 22:01 image.raw</div></div><div><br></div><div>All the images contain exactly the same data.</div><div><br></div><div>Now, how can we optimize your image on upload? we can't.</div><div><br></div><div>When uploading from the UI, our code run in the browser</div><div>and we don't have access to your file system.</div><div><br></div><div>When using the oVirt SDK, you write the code for uploading so you can</div><div>do the conversion if want to save upload time and bandwidth and can</div><div>spend the time to do the conversion.</div><div><br></div><div>We can provide an upload command line tool that will convert</div><div>and compress images before upload, and will use the oVirt SDK</div><div>to upload the images.</div><div><br></div><div>But I think it will be simpler and easier to maintain to support</div><div>compression when uploading or downloading data. This is</div><div>already supported by browsers and common tools like curl,</div><div>and it works with any file format without conversion.</div><div><br></div><div>I hope I convinced you this time ;-)</div><div><br></div><div>Nir</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Thanks,</div><div>Gianluca</div><div><br></div><div><br></div></div></div></div>
</blockquote></div></div>