[Openstack-operators] [Glance] [Nova] Multiple backends / Qcow Derived Images

Rui Chen chenrui.momo at gmail.com
Thu Jan 5 08:47:06 UTC 2017


Ah, Adam, got your point, I found two related Nova blueprints that were
similar with your idea,
but there are not any activities about them from 2014, I hadn't dive deep
into these comments,
you might get some background information at there.

https://blueprints.launchpad.net/nova/+spec/image-precacher
https://blueprints.launchpad.net/nova/+spec/cache-aware-weigher

2017-01-05 6:22 GMT+08:00 Blair Bethwaite <blair.bethwaite at gmail.com>:

> Hi Adam,
>
> On 5 January 2017 at 08:48, Adam Lawson <alawson at aqorn.com> wrote:
> > Just a friendly bump. To clarify, the ideas being tossed around are to
> host
> > QCOW images on each Compute node so the provisioning is faster (i.e. less
> > dependency on network connectivity to a shared back-end). I need to know
> if
> > this is possible or not. So far, I've seen nothing that suggests that it
> is
> > but i want to confirm that.
>
> If you are using qcow based ephemeral disks then you will have
> something like a /var/lib/nova/instances/_base/ dir on each
> nova-compute. That directory holds the backing files for each
> "derived" disk file in /var/lib/nova/instances/<UUID>/. It also acts
> as a local image cache - their are corresponding nova-compute config
> options controlling whether and how often unused base files get
> removed. See e.g.
> http://www.pixelbeat.org/docs/openstack_libvirt_images/ for a great
> dive into the possibilities.
>
> > Also, derived images is a QCOW thing[1], I'm wondering if creating these
> > dynamically is supported by Nova and/or Glance.
>
> The default (typical?) configuration does use qcow layering, but you
> can also change your nova-compute settings to e.g. force all instances
> to run off raw disk files.
>
> --
> Cheers,
> ~Blairo
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170105/a23d45df/attachment.html>


More information about the OpenStack-operators mailing list