<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 20, 2017 at 8:39 PM, Adam Litke <span dir="ltr">&lt;<a href="mailto:alitke@redhat.com" target="_blank">alitke@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Ok, thanks for clarifying that.  So it looks like the temporary snapshot was already merged/deleted.  As part of that operation, vdsm calculates how large the original volume would have to be (LV size) in order to guarantee that the base volume has enough space for the merge to complete.  It looks like in this case we decided that value was the virtual size + 10% for qcow2 metadata.  If your base volume was only about 16G allocated prior to all of this than it seems we were way too conservative.  Did you remove the snapshot quickly after the move completed?  One thing that could cause this is if you wrote about 12-15 GB of data into the that disk after moving but before deleting the temporary snapshot.<br><br></div>Do you happen to have the vdsm logs from the host running the VM and the host that was acting SPM (if different) from during the time you experienced this issue?  <br></div><br></blockquote></div><br></div><div class="gmail_extra">I executed some snapshot creation to test backup so with following live merge after a couple of minutes without using that much VM in the mean time.<br></div><div class="gmail_extra">And I also tested storage migration.<br></div><div class="gmail_extra">I have not the logs but I can try to reproduce similar operations and then send new log files if the anomaly persists...<br><br></div><div class="gmail_extra"><br></div></div>