<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 20, 2017 at 11:39 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"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><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"><div class="gmail_extra"><span class="gmail-m_3669065863614619662gmail-"><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_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"><span class="gmail-m_3669065863614619662gmail-m_6153820332550733314gmail-"><div dir="ltr"><div><div><div></div><br></div></div></div></span></blockquote></div></div></div></blockquote></div><br></span>Yes, the VM is active.<br>In this moment the disk name seems to be without the final "he" letters....<br></div></div></blockquote><div><br></div></span><div>Seems to be an issue between my keyboard and chair :-)</div></div></div></div></blockquote><div><br></div><div>Actually you wrote the correct name that I intercepted during live storage migration.</div><div>The output disk of the migration was </div><div>/rhev/data-center/mnt/blockSD/5ed04196-87f1-480e-9fee-9dd450a3b53b/images/6af3dfe5-6da7-48e3-9eb0-1e9596aca9d3/9af3574d-dc83-485f-b906-0970ad09b660he</div><div><br></div><div>But I see that indeed the name is now without the final "he" part... don't know if the suffix is in place only during the migration as a sort of notifier/lock.... </div><div><br></div><div><div>[g.cecchi@ovmsrv07 ~]$ ll /rhev/data-center/mnt/blockSD/5ed04196-87f1-480e-9fee-9dd450a3b53b/images/6af3dfe5-6da7-48e3-9eb0-1e9596aca9d3/9af3574d-dc83-485f-b906-0970ad09b660 </div><div>lrwxrwxrwx. 1 vdsm kvm 78 Feb 13 22:39 /rhev/data-center/mnt/blockSD/5ed04196-87f1-480e-9fee-9dd450a3b53b/images/6af3dfe5-6da7-48e3-9eb0-1e9596aca9d3/9af3574d-dc83-485f-b906-0970ad09b660 -> /dev/5ed04196-87f1-480e-9fee-9dd450a3b53b/9af3574d-dc83-485f-b906-0970ad09b660</div><div>[g.cecchi@ovmsrv07 ~]$ </div></div><div><br></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_extra"><div class="gmail_quote"><span class="gmail-"><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_extra">[root@ovmsrv07 ~]# qemu-img check /dev/5ed04196-87f1-480e-9fee-9<wbr>dd450a3b53b/9af3574d-dc83-485f<wbr>-b906-0970ad09b660 <br>No errors were found on the image.<br>41734/491520 = 8.49% allocated, 3.86% fragmented, 0.00% compressed clusters<br>Image end offset: 2736128000<br></div></div></blockquote><div><br></div></span><div>So you have 2.5 G image in 33G lv?</div></div></div></div></blockquote><div><br></div><div>Yes, I created a 30Gb disk but in the mean time only a small part of it is used. Inside the VM:</div><div><br></div><div><div>[root@c7service ~]# lsblk </div><div>NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT</div><div>sda 8:0 0 30G 0 disk </div><div>├─sda1 8:1 0 1G 0 part /boot</div><div>└─sda2 8:2 0 29G 0 part </div><div> ├─cl-root 253:0 0 26G 0 lvm /</div><div> └─cl-swap 253:1 0 3G 0 lvm [SWAP]</div><div>sr0 11:0 1 1024M 0 rom </div><div>[root@c7service ~]# </div></div><div><br></div><div> [root@c7service ~]# df -h</div><div>Filesystem Size Used Avail Use% Mounted on</div><div>/dev/mapper/cl-root 26G 2.2G 24G 9% /</div><div>devtmpfs 2.0G 0 2.0G 0% /dev</div><div>tmpfs 2.0G 0 2.0G 0% /dev/shm</div><div>tmpfs 2.0G 17M 2.0G 1% /run</div><div>tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup</div><div>/dev/sda1 1014M 150M 865M 15% /boot</div><div>tmpfs 396M 0 396M 0% /run/user/0</div><div>[root@c7service ~]# </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_extra"><div class="gmail_quote"><div><br></div><div>If this is internal volume, you can reduce it to the next power</div><div>of 128m - 2688m</div><div><br></div><div>If this is active volume, you want to leave empty space at the end.</div><div>since you are using 4G extent size, you can reduce it to 6784m.</div><div><br></div><div>To reduce the lv:</div><div><br></div><div>1. Move storage domain to maintenance</div><div><br></div><div>2. Check again the image end offset using qemu-img check</div><div><br></div><div> lvchange -ay vg-name/lv-name</div><div> qemu-img check /dev/vg-name/lv-name</div><div> lvchange -an vg-name/lv-name</div><div><br></div><div>2. use lvreduce (update the size if needed)</div><div><br></div><div> lvreduce -L 2688m vg-name/lv-name</div><div><br></div><div>3. Actvate the storage domain</div><div><br></div><div>We are working now on integrating this into the flows<br></div><div>like cold and live merge.</div><span class="gmail-HOEnZb"><font color="#888888"><div><br></div><div>Nir</div></font></span></div></div></div>
</blockquote></div><br></div><div class="gmail_extra">Thanks for the information, that could be useful</div><div class="gmail_extra">But my concern was not to reduce the disk size in this case: I'll let the free space for future applications I have to install.</div><div class="gmail_extra">My concern was that one would expect to see actual size of a thin provisioned disk always less or equal the virtual one and not the opposite.... </div></div>