On 01/23/2017 11:29 AM, Marco Marino wrote:
At the moment I have:
volume_clear=zero
volume_clear_size=30 <-- MBR will be deleted here!
with tick provisioning
I think this can be a good solution in my case. Let me know what do you think
about this.
If security is not a concern then that's fine.
At the moment I have:
volume_clear=zero
volume_clear_size=30 <-- MBR will be deleted here!
with tick provisioning
I think this can be a good solution in my case. Let me know what do you
think about this.
Thank you
Marco
2017-01-23 17:21 GMT+01:00 Chris Friesen :
>
On 01/21/2017 03:00 AM, Marco Marino wrote:
Really thank you!! It's difficult for me find help on cinder and I think this is
the right place!
@Duncan, if my goal is to speeding up bootable volume creation, I can avoid to
use thin provisioning. I can use image cache and in this way the "retrieve
Really thank you!! It's difficult for me find help on cinder and I think
this is the right place!
@Duncan, if my goal is to speeding up bootable volume creation, I can avoid
to use thin provisioning. I can use image cache and in this way the
"retrieve from glance" and the "qemu-img convert to RAW"
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
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
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