<div dir="ltr"><div>Hi George</div><div><br></div><div>Thanks for your feedback</div><div><br></div>Yes, it makes sense, but most of our users upload their own images. Educating them to upload the image twice and setting the metadata on these images won't be easy at all <div><br></div><div>Thanks, Massimo</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-04-05 16:23 GMT+02:00 George Mihaiescu <span dir="ltr"><<a href="mailto:lmihaiescu@gmail.com" target="_blank">lmihaiescu@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi Massimo,<br><br></div>You can upload the images twice, in both qcow2 and raw format, then create a host aggregate for your "local-disk" compute nodes and set its metadata to match the property you'll set on your qcow2 images.<br><br></div>When somebody will start a qcow2 version of the image, it will be scheduled on your compute nodes with local disk and pull the qcow2 image from Glance.<br><br></div>Does it make sense?<br><br></div>George<br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Wed, Apr 5, 2017 at 10:05 AM, Massimo Sgaravatto <span dir="ltr"><<a href="mailto:massimo.sgaravatto@gmail.com" target="_blank">massimo.sgaravatto@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div>Hi</div><div><br></div><div>Currently in our Cloud we are using a gluster storage for cinder and glance.</div><div>For nova we are using a shared file system (implemented using gluster) for part of the compute nodes; the rest of the compute nodes use the local disk.</div><div><br></div><div>We are now planning the replacement of gluster with ceph. The idea is therefore to use ceph for cinder, glance. Ceph would be used for nova but just for a set of compute nodes  (the other compute nodes would keep using the local disk).</div><div><br></div><div>In such configuration I see a problem with the choice of the best format type</div><div>for images.</div><div><br></div><div><div>As far as I understand (please correct me if am wrong) the ideal setup would be using raw images for VMs targeted to compute nodes using ceph, and qcow2 images for VMs targeted to compute nodes using the local disk for nova.</div><div>In fact starting a VM using a qcow2 image on a compute node using ceph for nova works but it is quite inefficient since the qcow2 image must be first downloaded in /var/lib/nova/instances/_base and then converted into raw. This also means that some space is needed on the local disk.</div><div><br></div><div>And if you start a VM using a raw image on a a compute node using the local disk for nova, the raw image (usually quite big) must be downloaded on the compute node, and this is less efficient wrt a qcow2 image. It is true that the qcow2 is then converted into raw, but I think that most of the time is taken in downloading the image.</div></div><div><br></div><div><div>Did I get it right ?</div><div>Any advice ?</div><div><br></div><div>Thanks, Massimo</div></div><div><br></div></div>
<br></div></div>______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.open<wbr>stack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-operators</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>