Bug 891350

Summary:	Use virt-resize on disk images instead of just manually extending the raw disk and using resize2fs directly
Product:	Red Hat OpenStack	Reporter:	Perry Myers <pmyers>
Component:	openstack-nova	Assignee:	Pádraig Brady <pbrady>
Status:	CLOSED WONTFIX	QA Contact:	Jaroslav Henner <jhenner>
Severity:	unspecified	Docs Contact:
Priority:	medium
Version:	2.0 (Folsom)	CC:	dallan, jhenner, pbrady
Target Milestone:	beta	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-06-18 16:50:51 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Perry Myers 2013-01-02 16:51:56 UTC

Description of problem:
Currently Nova extends only raw disk images and can on deal with resizing partitions of type ext2/3/4 (or unpartitioned space).

If we utilize virt-resize from libguestfs we can handle resizing VGs/LVM and other types of filesystems.

virt-resize also does better error checking to make sure the operation succeeded.

Comment 1 seth vidal 2013-02-22 06:43:34 UTC

looking in folsom - it seems like qcow2 and raw images get extended - but unless we have an initramfs doing a growroot then it won't work w/o a reboot of the instance.

Comment 2 Pádraig Brady 2013-04-02 16:45:24 UTC

Upstream are leaning towards (newer) cloud-init doing this within the image,
rather than externally with virt-resize.

Comment 4 Pádraig Brady 2013-06-18 16:50:51 UTC

For more concrete details on using cloud-utils to auto resize from within the guest on boot, see:
http://lists.openstack.org/pipermail/openstack-operators/2013-June/003131.html