libvirt: better performance for resizing backing files

Bug #1087031 reported by Vish Ishaya
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Fix Released
Michael Still

Bug Description

Currently backing files are resized (from <uuid> to <uuid>_40 for example) using a copy, which is extremely slow. It would be nice to either:

a) allow resizing by making the <uuid>_40 a qcow image with <uuid> as a backing file and performing a resize on the qcow.


b) allow the disk file to directly back to <uuid> and perform the resize on disk directly

both of these have some concerns when relating to image cache cleanup, but overall option b) seems far better. It also makes resizing the image later much easier.

Changed in nova:
assignee: nobody → Michael Still (mikalstill)
status: New → Triaged
importance: Undecided → Low
Changed in nova:
status: Triaged → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (master)

Submitter: Jenkins
Branch: master

commit c82be9f4b997d252cfc84350a067a64d6d4b380b
Author: Michael Still <email address hidden>
Date: Mon Dec 17 14:56:19 2012 +1100

    libvirt: Skip intermediate base files with qcow2.

    Instead of having two files in _base (the original and a resized
    copy), let's just keep the originals and resize with the qcow2
    image in the instance's directory. This will reduce the size of
    _base and simplify cleanup. This also simplifies resizing of
    instance disk images later.

    Resolves bug 1087031.

    Change-Id: Id91426e3cb9f75f31339b5156785e3782a4cb98f

Changed in nova:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in nova:
milestone: none → grizzly-2
status: Fix Committed → Fix Released
Revision history for this message
Pádraig Brady (p-draigbrady) wrote :

I've a query about the change.

Now resizes are always done on qcow file in the instance directory.
That will introduce a possibly unexpected change when using
unpartitioned ext[234] images, as they'll no longer have their
file system resized up (as resize2fs will fail on the qcow2 file).

Maybe we document this in release notes, that the limited
file system resizing is no longer supported?
Or perhaps we key this new behaviour on whether the
image in base could be resized (disk.can_resize_fs(_base_image, size))

Thierry Carrez (ttx)
Changed in nova:
milestone: grizzly-2 → 2013.1
Revision history for this message
Pádraig Brady (p-draigbrady) wrote :

The question in comment 2 is now addressed with the following since Havana milestone 3

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.