<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Mar 26, 2018 at 10:59 AM Richard W.M. Jones <<a href="mailto:rjones@redhat.com">rjones@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Mar 25, 2018 at 08:05:14PM +0000, Nir Soffer wrote:<br>
> On Sun, Mar 25, 2018 at 2:41 PM Richard W.M. Jones <<a href="mailto:rjones@redhat.com" target="_blank">rjones@redhat.com</a>><br>> When a vm is running, vdsm monitor the allocated space and ask the SPM<br>
> host to allocated more space when the highest write offset is too high, so<br>
> the disk looks like a thin provisioned disk to the vm. This mechanism is<br>
> not available for storage operations, and all of them specify initial_size<br>
> when converting images to qcow2 format.<br>
<br>
This is going to cause problems for backup applications too.  There's<br>
no way in general they can estimate the data to be transferred.<br></blockquote><div><br></div><div>To backup a chain of images, you need to reconstruct the chain remotely</div><div>on the machine doing the restore, since the qcow2 header must have correct</div><div>backing file when uploaded. So I guess backup vendor will build the chain </div><div>and upload the real files, so this should not be an issue.</div><div><br></div><div>If they want to do something more fancy, like creating empty qcow2 file for</div><div>setting up the backing file, and streaming the data separately, they can</div><div>estimate the required allocation using the number of 64k (assuming standard</div><div>cluster size) guest sectors, and the virtual size.</div><div><br></div><div>See here how vdsm estimate this since 4.1:</div><div><a href="https://github.com/oVirt/vdsm/blob/master/lib/vdsm/storage/qcow2.py">https://github.com/oVirt/vdsm/blob/master/lib/vdsm/storage/qcow2.py</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> If there is no way to estimate the size and you must allocate the entire<br>
> image, we can add a shrink step in upload finalization, to shrink the image<br>
> size to optimal size. We are already doing this in several flows that<br>
> cannot estimate the final disk size and do over allocation.<br>
<br>
I guess we'll need something like that.<br></blockquote><div><br></div><div>I think we can implement this for 4.2.z. We will open a new RFE for this.</div><div><br></div><div>Nir</div></div></div>