<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Two things, first info does not show how much disk is used du does.  Second, the semantics count, copy is different than clone and flatten.  Clone and flatten which should happen if you have things working correctly is much faster than copy.  If you are using copy then you may be limited by the number of management ops in flight, this is a setting for more recent versions of ceph.  I don’t know if copy skips zero byte objects but clone and flatten certainly do.  You need to be sure that you have the proper settings in nova.conf for discard/unmap as well as using hw_scsi_model=virtio-scsi and hw_disk_bus=scsi in the image properties.  Once discard is working and you have the qemu guest agent running in your instances you can force them to do a fstrim to reclaim space as an additional benefit.<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 1, 2017, at 3:50 PM, John Petrini <<a href="mailto:jpetrini@coredial.com" class="">jpetrini@coredial.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Maybe I'm just not understanding but when I create a nova snapshot the snapshot happens at RBD in the ephemeral pool and then it's copied to the images pool. This results in a full sized image rather than a snapshot with a reference to the parent.<div class=""><br class=""></div><div class="">For example below is a snapshot of an ephemeral instance from our images pool. It's 80GB, the size of the instance, so rather than just capturing the state of the parent image I end up with a brand new image of the same size. It takes a long time to create this copy and causes high IO during the snapshot.</div><div class=""><br class=""></div><div class=""><div class="">rbd --pool images info d5404709-cb86-4743-b3d5-1dc7fba836c1</div><div class="">rbd image 'd5404709-cb86-4743-b3d5-1dc7fba836c1':</div><div class=""><span class="gmail-Apple-tab-span" style="white-space:pre">        </span>size 81920 MB in 20480 objects</div><div class=""><span class="gmail-Apple-tab-span" style="white-space:pre">      </span>order 22 (4096 kB objects)</div><div class=""><span class="gmail-Apple-tab-span" style="white-space:pre">  </span>block_name_prefix: rbd_data.93cdd43ca5efa8</div><div class=""><span class="gmail-Apple-tab-span" style="white-space:pre">  </span>format: 2</div><div class=""><span class="gmail-Apple-tab-span" style="white-space:pre">   </span>features: layering, striping</div><div class=""><span class="gmail-Apple-tab-span" style="white-space:pre">        </span>flags: </div><div class=""><span class="gmail-Apple-tab-span" style="white-space:pre">        </span>stripe unit: 4096 kB</div><div class=""><span class="gmail-Apple-tab-span" style="white-space:pre">        </span>stripe count: 1</div><div class=""><br class=""></div><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="gmail_signature">
<div class="">
<div style="letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; word-wrap: break-word;" class=""><p style="background-color:rgb(255,255,255);margin-top:8px;margin-bottom:8px;color:rgb(51,51,51);line-height:1.6" class=""><span style="font-size:14pt" class="">John Petrini</span></p></div></div><img src="https://t.xink.io/Tracking/Impression/Nx4AAGORAACukSoA0" height="1px" width="1px" style="border: none; display: none !important;" class=""></div></div>
<br class=""><div class="gmail_quote">On Tue, Aug 1, 2017 at 3:24 PM, Mike Lowe <span dir="ltr" class=""><<a href="mailto:jomlowe@iu.edu" target="_blank" class="">jomlowe@iu.edu</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">There is no upload if you use Ceph to back your glance (like you should), the snapshot is cloned from the ephemeral pool into the the images pool, then flatten is run as a background task.  Net result is that creating a 120GB image vs 8GB is slightly faster on my cloud but not at all what I’d call painful.</div><div class=""><br class=""></div><div class="">Running nova image-create for a 8GB image:</div><div class=""><br class=""></div><div class=""><div class="">real<span class="gmail-m_-2022544241925408475Apple-tab-span" style="white-space:pre-wrap"> </span>0m2.712s</div><div class="">user<span class="gmail-m_-2022544241925408475Apple-tab-span" style="white-space:pre-wrap">     </span>0m0.761s</div><div class="">sys<span class="gmail-m_-2022544241925408475Apple-tab-span" style="white-space:pre-wrap">      </span>0m0.225s</div></div><div class=""><br class=""></div><div class="">Running nova image-create for a 128GB image:</div><div class=""><br class=""></div><div class=""><div class="">real<span class="gmail-m_-2022544241925408475Apple-tab-span" style="white-space:pre-wrap">       </span>0m2.436s</div><div class="">user<span class="gmail-m_-2022544241925408475Apple-tab-span" style="white-space:pre-wrap">     </span>0m0.774s</div><div class="">sys<span class="gmail-m_-2022544241925408475Apple-tab-span" style="white-space:pre-wrap">      </span>0m0.225s</div></div><div class=""><div class="gmail-h5"><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 1, 2017, at 3:07 PM, John Petrini <<a href="mailto:jpetrini@coredial.com" target="_blank" class="">jpetrini@coredial.com</a>> wrote:</div><br class="gmail-m_-2022544241925408475Apple-interchange-newline"><div class=""><div dir="ltr" class="">Yes from Mitaka onward the snapshot happens at the RBD level which is fast. It's the flattening and uploading of the image to glance that's the major pain point. Still it's worlds better than the qemu snapshots to the local disk prior to Mitaka.</div><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="gmail-m_-2022544241925408475gmail_signature">
<div class="">
<div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word" class=""><p style="background-color:rgb(255,255,255);margin-top:8px;margin-bottom:8px;color:rgb(51,51,51);line-height:1.6" class=""><span style="font-size:14pt" class="">John Petrini</span></p><p style="background-color:rgb(255,255,255);margin-top:8px;margin-bottom:8px;font-family:Helvetica,Verdana,Arial,sans-serif;font-size:0.85em;color:rgb(51,51,51);line-height:1.6" class=""><span style="font-size:9pt" class="">Platforms Engineer   //   <b class="">CoreDial, LLC</b>   //   <a href="http://coredial.com/" style="color:rgb(35,104,179);text-decoration:none" title="CoreDial" target="_blank" class="">coredial.com</a>   //  <wbr class=""> <a href="https://twitter.com/coredial" style="color:rgb(17,85,204)" target="_blank" class=""><img alt="Twitter" border="0" src="http://www.stratusinteractive.com/coredial/email/twitter.gif" style="vertical-align: text-bottom;" class=""></a>   <a href="http://www.linkedin.com/company/99631" style="color:rgb(17,85,204)" target="_blank" class=""><img alt="LinkedIn" border="0" src="http://www.stratusinteractive.com/coredial/email/linkedin.gif" style="vertical-align: text-bottom;" class=""></a>   <a href="https://plus.google.com/104062177220750809525/posts" style="color:rgb(17,85,204)" target="_blank" class=""><img alt="Google Plus" border="0" src="http://www.stratusinteractive.com/coredial/email/googleplus.gif" style="vertical-align: text-bottom;" class=""></a>   <a href="http://success.coredial.com/blog" style="color:rgb(17,85,204)" target="_blank" class=""><img alt="Blog" border="0" src="http://www.stratusinteractive.com/coredial/email/rss.gif" style="vertical-align: text-bottom;" class=""></a> <br class="">
751 Arbor Way, Hillcrest I, Suite 150, Blue Bell, PA 19422<br class="">
<b class="">P:</b> <a href="tel:(215)%20297-4400" value="+12152974400" target="_blank" class="">215.297.4400 x232</a>   //   <b class="">F: </b><a href="tel:(215)%20297-4401" value="+12152974401" target="_blank" class="">215.297.4401</a>   //   <b class="">E:<wbr class=""> </b><a href="mailto:jpetrini@coredial.com" target="_blank" class="">jpetrini@coredial.com</a></span></p>
</div>
</div>
<div style="margin:0px;padding:0px;display:block;width:100%;height:auto" class=""><a href="https://t.xink.io/Tracking/Index/a64BAGORAACukSoA0" target="_blank" class=""><img alt="" border="0" height="80" src="https://i.xink.io/Images/Get/N63353/c4.jpg" width="600" class=""></a><br class="">
<br class="">
<span style="font-size:9pt" class="">The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission,  dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.</span><br class="">
<br class="">
 </div><img src="https://t.xink.io/Tracking/Impression/Nx4AAGORAACukSoA0" height="1px" width="1px" style="border: none; display: none !important;" class=""></div></div>
<br class=""><div class="gmail_quote">On Tue, Aug 1, 2017 at 2:53 PM, Mike Lowe <span dir="ltr" class=""><<a href="mailto:jomlowe@iu.edu" target="_blank" class="">jomlowe@iu.edu</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="">Strictly speaking I don’t think this is the case anymore for Mitaka or later.  Snapping nova does take more space as the image is flattened, but the dumb download then upload back into ceph has been cut out.  With careful attention paid to discard/TRIM I believe you can maintain the thin provisioning properties of RBD.  The workflow is explained here.  <a href="https://www.sebastien-han.fr/blog/2015/10/05/openstack-nova-snapshots-on-ceph-rbd/" target="_blank" class="">https://www.sebastien-han.fr/<wbr class="">blog/2015/10/05/openstack-nova<wbr class="">-snapshots-on-ceph-rbd/</a><div class=""><div class="gmail-m_-2022544241925408475h5"><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 1, 2017, at 11:14 AM, John Petrini <<a href="mailto:jpetrini@coredial.com" target="_blank" class="">jpetrini@coredial.com</a>> wrote:</div><br class="gmail-m_-2022544241925408475m_-2678311552290896516Apple-interchange-newline"><div class=""><div dir="ltr" class="">Just my two cents here but we started out using mostly Ephemeral storage in our builds and looking back I wish we hadn't. Note we're using Ceph as a backend so my response is tailored towards Ceph's behavior.<div class=""><br class=""></div><div class="">The major pain point is snapshots. When you snapshot an nova volume an RBD snapshot occurs and is very quick and uses very little additional storage, however the snapshot is then copied into the images pool and in the process is converted from a snapshot to a full size image. This takes a long time because you have to copy a lot of data and it takes up a lot of space. It also causes a great deal of IO on the storage and means you end up with a bunch of "snapshot images" creating clutter. On the other hand volume snapshots are near instantaneous without the other drawbacks I've mentioned.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">On the plus side for ephemeral storage; resizing the root disk of images works better. As long as your image is configured properly it's just a matter of initiating a resize and letting the instance reboot to grow the root disk. When using volumes as your root disk you instead have to shutdown the instance, grow the volume and boot.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">I hope this help! If anyone on the list knows something I don't know regarding these issues please chime in. I'd love to know if there's a better way.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">Regards,</div><div class="gmail_extra"><div class=""><div class="gmail-m_-2022544241925408475m_-2678311552290896516gmail_signature">
<div class="">
<div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word" class=""><p style="background-color:rgb(255,255,255);margin-top:8px;margin-bottom:8px;color:rgb(51,51,51);line-height:1.6" class=""><span style="font-size:14pt" class="">John Petrini</span></p></div></div><img src="https://t.xink.io/Tracking/Impression/Nx4AAGORAACukSoA0" height="1px" width="1px" style="border: none; display: none !important;" class=""></div></div>
<br class=""><div class="gmail_quote">On Tue, Aug 1, 2017 at 10:50 AM, Kimball, Conrad <span dir="ltr" class=""><<a href="mailto:conrad.kimball@boeing.com" target="_blank" class="">conrad.kimball@boeing.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US" class="">
<div class="gmail-m_-2022544241925408475m_-2678311552290896516m_4975858222606055292WordSection1"><p class="MsoNormal">In our process of standing up an OpenStack internal cloud we are facing the question of ephemeral storage vs. Cinder volumes for instance root disks.<u class=""></u><u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="MsoNormal">As I look at public clouds such as AWS and Azure, the norm is to use persistent volumes for the root disk.  AWS started out with images booting onto ephemeral disk, but soon after they released Elastic Block Storage and ever since the clear
 trend has been to EBS-backed instances, and now when I look at their quick-start list of 33 AMIs, all of them are EBS-backed.  And I’m not even sure one can have anything except persistent root disks in Azure VMs.<u class=""></u><u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="MsoNormal">Based on this and a number of other factors I think we want our user normal / default behavior to boot onto Cinder-backed volumes instead of onto ephemeral storage.  But then I look at OpenStack and its design point appears to be booting
 images onto ephemeral storage, and while it is possible to boot an image onto a new volume this is clumsy (haven’t found a way to make this the default behavior) and we are experiencing performance problems (that admittedly we have not yet run to ground).<u class=""></u><u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="MsoNormal">So …<u class=""></u><u class=""></u></p><p class="gmail-m_-2022544241925408475m_-2678311552290896516m_4975858222606055292MsoListParagraph" style="margin-left:0.25in">
<u class=""></u><span style="font-family:Symbol" class=""><span class="">·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:"Times New Roman"" class="">        
</span></span></span><u class=""></u>Are other operators routinely booting onto Cinder volumes instead of ephemeral storage?<u class=""></u><u class=""></u></p><p class="gmail-m_-2022544241925408475m_-2678311552290896516m_4975858222606055292MsoListParagraph" style="margin-left:0.25in">
<u class=""></u><span style="font-family:Symbol" class=""><span class="">·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:"Times New Roman"" class="">        
</span></span></span><u class=""></u>What has been your experience with this; any advice?<u class=""></u><u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="MsoNormal"><i class=""><span style="font-size:12pt;color:rgb(31,73,125)" class="">Conrad Kimball<u class=""></u><u class=""></u></span></i></p><p class="MsoNormal"><span style="font-size:10pt;color:rgb(31,73,125)" class="">Associate Technical Fellow<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:10pt;color:rgb(31,73,125)" class="">Chief Architect, Enterprise Cloud Services<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:10pt;color:rgb(31,73,125)" class="">Application Infrastructure Services / Global IT Infrastructure / Information Technology & Data Analytics<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:10pt;color:rgb(31,73,125)" class=""><a href="mailto:conrad.kimball@boeing.com" target="_blank" class=""><span style="color:rgb(5,99,193)" class="">conrad.kimball@boeing.com</span></a><u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:10pt;color:rgb(31,73,125)" class="">P.O. Box 3707, Mail Code 7M-TE<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:10pt;color:rgb(31,73,125)" class="">Seattle, WA  98124-2207<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:10pt;color:rgb(31,73,125)" class="">Bellevue 33-11 bldg, office 3A6-3.9<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:10pt;color:rgb(31,73,125)" class="">Mobile:  <a href="tel:(425)%20591-7802" value="+14255917802" target="_blank" class="">425-591-7802</a><u class=""></u><u class=""></u></span></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p>
</div>
</div>

<br class="">______________________________<wbr class="">_________________<br class="">
OpenStack-operators mailing list<br class="">
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank" class="">OpenStack-operators@lists.open<wbr class="">stack.org</a><br class="">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank" class="">http://lists.openstack.org/cgi<wbr class="">-bin/mailman/listinfo/openstac<wbr class="">k-operators</a><br class="">
<br class=""></blockquote></div><br class=""></div></div>
______________________________<wbr class="">_________________<br class="">OpenStack-operators mailing list<br class=""><a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank" class="">OpenStack-operators@lists.open<wbr class="">stack.org</a><br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank" class="">http://lists.openstack.org/cgi<wbr class="">-bin/mailman/listinfo/openstac<wbr class="">k-operators</a><br class=""></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></div>
</div></blockquote></div><br class=""></div></body></html>