[Openstack-operators] rbd ephemeral storage, very slow deleting...
heut2008 at gmail.com
Thu Sep 25 02:40:56 UTC 2014
Fortunately, this bug get fixed in final Havana stable release 2013.2.4
see https://review.openstack.org/#/c/87455, but you need to be aware that
this change also
renames instance disk name from instance-0000000xx to uuid format, so after
upgrade to this version, you should ensure not previous instances exists or
old instance disk files in rbd store can't be removed. Sorry I didn't catch
this early, or this can be improved within a line of code to get fixed.
On Thu, Sep 25, 2014 at 10:20 AM, David Medberry <openstack at medberry.net>
> Yes this 1024x bug was a pretty wide spread bug.
> On Wed, Sep 24, 2014 at 8:17 PM, Sam Morrison <sorrison at gmail.com> wrote:
>> There was a bug in Havana where it would create the underlying RBD volume
>> at 1024 times the actual size. We didn’t notice this until we started
>> deleting instances and they took forever.
>> Could be the case with you too?
>> See https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1219658
>> I don’t think this made it into Havana sadly.
>> On 25 Sep 2014, at 5:45 am, Jonathan Proulx <jon at jonproulx.com> wrote:
>> > Hi All,
>> > Just started experimenting with RBD (ceph) back end for ephemeral
>> > storage on some of my compute nodes.
>> > I have it launching instances just fine, but when I try and delete
>> > them libvirt shows the instances are gone, but OpensStack lists them
>> > in 'deleting' state and the rbd process on the hypervisor spins madly
>> > at about 300% cpu ...
>> > ...and now approx 18min later they have finally fully terminated, why
>> so long?
>> > -Jon
>> > _______________________________________________
>> > OpenStack-operators mailing list
>> > OpenStack-operators at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-operators