3:11 a.m.
This is a multi-part message in MIME format.
--------------DFD541D40E712C15A95C6FB1
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Hello,
Sending this here to share knowledge.
Here is what I learned from many BZ and mailing list posts readings. I'm
not working at Redhat, so please correct me if I'm wrong.
We are using thin-provisioned block storage LUNs (Equallogic), on which
oVirt is creating numerous Logical Volumes, and we're very happy with it.
When oVirt is removing a virtual disk, the SAN is not informed, because
the LVM layer is not sending the "issue_discard" flag.
/etc/lvm/lvm.conf is not the natural place to try to change this
parameter, as VDSM is not using it.
Efforts are presently made to include issue_discard setting support
directly into vdsm.conf, first on a datacenter scope (4.0.x), then per
storage domain (4.1.x) and maybe via a web GUI check-box. Part of the
effort is to make sure every bit of a planned to be removed LV get wiped
out. Part is to inform the block storage side about the deletion, in
case of thin provisioned LUNs.
https://bugzilla.redhat.com/show_bug.cgi?id=1342919
https://bugzilla.redhat.com/show_bug.cgi?id=981626
--
Nicolas ECARNOT
On Mon, Oct 3, 2016 at 2:24 PM, Nicolas Ecarnot <nicolas(a)ecarnot.net
<mailto:nicolas@ecarnot.net>> wrote:
Yaniv,
As a pure random way of web surfing, I found that you posted on
twitter an information about DISCARD support.
(https://twitter.com/YanivKaul/status/773513216664174592
<https://twitter.com/YanivKaul/status/773513216664174592>)
I did not dig any further, but has it any relation with the fact
that so far, oVirt did not reclaim lost storage space amongst its
logical volumes of its storage domains?
A BZ exist about this, but one was told no work would be done about
it until 4.x.y, so now we're there, I was wondering if you knew more?
Feel free to send such questions on the mailing list (ovirt users or
devel), so other will be able to both chime in and see the response.
We've supported a custom hook for enabling discard per disk (which is
only relevant for virtio-SCSI and IDE) for some versions now (3.5 I
believe).
We are planning to add this via a UI and API in 4.1.
In addition, we are looking into discard (instead of wipe after delete,
when discard is also zero'ing content) as well as discard when removing LVs.
See:
http://www.ovirt.org/develop/release-management/features/storage/pass-dis...
http://www.ovirt.org/develop/release-management/features/storage/wipe-vol...
http://www.ovirt.org/develop/release-management/features/storage/discard-...
Y.
Best,
--
Nicolas ECARNOT
--------------DFD541D40E712C15A95C6FB1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div dir="ltr">Hello,<br>
<br>
Sending this here to share knowledge.<br>
<br>
Here is what I learned from many BZ and mailing list posts
readings. I'm not working at Redhat, so please correct me if I'm
wrong.<br>
<br>
We are using thin-provisioned block storage LUNs (Equallogic), on
which oVirt is creating numerous Logical Volumes, and we're very
happy with it.<br>
When oVirt is removing a virtual disk, the SAN is not informed,
because the LVM layer is not sending the "issue_discard" flag.<br>
<br>
/etc/lvm/lvm.conf is not the natural place to try to change this
parameter, as VDSM is not using it.<br>
<br>
Efforts are presently made to include issue_discard setting
support directly into vdsm.conf, first on a datacenter scope
(4.0.x), then per storage domain (4.1.x) and maybe via a web GUI
check-box. Part of the effort is to make sure every bit of a
planned to be removed LV get wiped out. Part is to inform the
block storage side about the deletion, in case of thin provisioned
LUNs.<br>
<br>
<a class="moz-txt-link-freetext"
href="https://bugzilla.redhat.com/show_bug.cgi?id=1342919">h...
<a class="moz-txt-link-freetext"
href="https://bugzilla.redhat.com/show_bug.cgi?id=981626">ht...
<br>
-- <br>
Nicolas ECARNOT<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Oct 3, 2016 at 2:24 PM, Nicolas
Ecarnot <span dir="ltr"><<a
href="mailto:nicolas@ecarnot.net"
target="_blank">nicolas(a)ecarnot.net</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">Yaniv,<br>
<br>
As a pure random way of web surfing, I found that you posted
on twitter an information about DISCARD support. (<a
href="https://twitter.com/YanivKaul/status/773513216664174592"
rel="noreferrer"
target="_blank">https://twitter.com/YanivKaul<wbr>/sta...
<br>
I did not dig any further, but has it any relation with the
fact that so far, oVirt did not reclaim lost storage space
amongst its logical volumes of its storage domains?<br>
<br>
A BZ exist about this, but one was told no work would be
done about it until 4.x.y, so now we're there, I was
wondering if you knew more?<br>
</blockquote>
<div><br>
</div>
<div>Feel free to send such questions on the mailing list
(ovirt users or devel), so other will be able to both chime
in and see the response.</div>
<div>We've supported a custom hook for enabling discard per
disk (which is only relevant for virtio-SCSI and IDE) for
some versions now (3.5 I believe).</div>
<div>We are planning to add this via a UI and API in 4.1.</div>
<div>In addition, we are looking into discard (instead of wipe
after delete, when discard is also zero'ing content) as well
as discard when removing LVs.</div>
<div>See:</div>
<div><a
href="http://www.ovirt.org/develop/release-management/features/stora...
<div><a
href="http://www.ovirt.org/develop/release-management/features/stora...
<div><a
href="http://www.ovirt.org/develop/release-management/features/stora...
<div><br>
</div>
<div>Y.</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">
<br>
Best,<span class="gmail-HOEnZb"><font
color="#888888"><br>
<br>
-- <br>
Nicolas ECARNOT<br>
</font></span></blockquote>
</div>
<br>
</div>
</div>
</body>
</html>
--------------DFD541D40E712C15A95C6FB1--