[openstack-dev] [cinder] Can I use lvm thin provisioning in mitaka?

Duncan Thomas duncan.thomas at gmail.com
Fri Jan 20 17:24:50 UTC 2017


There's also cinder functionality called the 'generic image cache' that
does this for you; see the (per-backend) config options:
image_volume_cache_enabled, image_volume_cache_max_size_gb and
image_volume_cache_max_count

On 20 January 2017 at 16:54, Chris Friesen <chris.friesen at windriver.com>
wrote:

> On 01/20/2017 04:07 AM, Marco Marino wrote:
>
>> Hi, I'm trying to use cinder with lvm thin provisioning. It works well
>> and I'd
>> like to know if there is some reason lvm thin should be avoided in mitaka
>> release. I'm trying to use with
>> max_over_subscription_ratio = 1.0
>> so I don't have problems with over subscription.
>> I using thin provisioning because it is fast (I think). More precisely,
>> my use
>> case is:
>>
>> - create one bootable volume. This is a long operation because cinder
>> download
>> the image from glance, qemu-img convert in raw format and then "dd" copy
>> the
>> image in the volume.
>> - Create a snapshot of the bootable volume. Really fast and reliable
>> because the
>> original volume is not used by any vm.
>> - Create a new volume from the snapshot. This is faster than create a new
>> bootable volume.
>>
>> Is this use correct? Can I deploy in the production environment (mitaka -
>> centos 7)
>> Thank you
>>
>
> For what it's worth we're using cinder with LVM thin provisioning in
> production with no overprovisioning.
>
> What you're proposing should work, you're basically caching the vanilla
> image as a cinder snapshot.
>
> If you wish to speed up volume deletion, you can set "volume_clear=none"
> in the cinder.conf file.
>
> Be aware that LVM thin provisioning will see a performance penalty the
> first time you write to a given disk block in a volume, because it needs to
> allocate a new block, zero it out, then write the new data to it.
>
> Chris
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
-- 
Duncan Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170120/a5e6a5ae/attachment.html>


More information about the OpenStack-dev mailing list