[openstack-dev] /var/lib/nova/instances fs filled up corrupting my Linux instances

Blair Bethwaite blair.bethwaite at gmail.com
Fri Mar 15 00:50:42 UTC 2013


On 15 March 2013 05:20, <openstack-operators-request at lists.openstack.org>wrote:

> From: Joe Topjian <joe.topjian at cybera.ca>
> To: Michael Still <mikal at stillhq.com>
> Cc: "openstack-operators at lists.openstack.org"
>         <openstack-operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] /var/lib/nova/instances fs filled
>         up corrupting my Linux instances
> Message-ID:
>         <CAD07=DcwCHv8p51zSHejMh50NJ+=
> DwY7OjxPsut-J_fXuXoxmw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I agree, if it is off by default, then the operator does risk running out
> of disk space. However, that problem and resolution is much more familiar
> to an operator than a missing _base image and resulting broken instances.


I think Joe has hit on the crux of this here. There are so many
permutations of possible deployments that it just isn't reasonable to test
everything, let alone even think of all the possibilities, e.g., to
continue with the current example, what happens if I have several different
pools of shared storage servicing distinct sets of compute nodes under the
same Nova deployment...? So it seems reasonable when looking at issues like
this that they should be viewed through the prism of a novice OS operator
(experienced sysadmin but little domain knowledge).

For this particular problem I don't think either the on or off default is
satisfactory. Nova needs to know whether it's dealing with shared storage
or not. Where it is, the default should be off, where it's not, on.

-- 
Cheers,
~Blairo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130315/396b5341/attachment.html>


More information about the OpenStack-dev mailing list