Bug 977028

This doesn't seem like an issue specific to the RHEL qcow2 image.  From the description it seems like it would be an issue specific to how OpenStack/RHOS uses those images.

Can you provide more detail?  Is there something missing from the RHEL qcow2 image that makes the resize in OpenStack fail?

Resizing the disk itself is the OpenStack responsibility and it is done.

The filesystem and partition size remains the original size. This resize should be done by the image itself.

This package https://bugzilla.redhat.com/show_bug.cgi?id=916087 has the tool for resizing the image at initrd/initramfs time, before the root filesystem mounted.

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

1. Install dracut-modules-growroot-0.20-0.4.bzr85.el6eng.noarch, depends on cloud-utils-growpart-0.27-9.el6eng.x86_64.
2. mkinitrd --force /boot/initramfs-$(uname -r).img $(uname -r)
3. lsinitrd /boot/initramfs-$(uname -r).img | grep growroot
4. fdisk -l
5. # qemu-img info rhel-guest-image-6.5-20131220.3.x86_64.qcow2 
image: rhel-guest-image-6.5-20131220.3.x86_64.qcow2
file format: qcow2
virtual size: 50G (53687091200 bytes)
disk size: 439M
cluster_size: 65536
# qemu-img resize rhel-guest-image-6.5-20131220.3.x86_64.qcow2 +100G
Image resized.
# qemu-img info rhel-guest-image-6.5-20131220.3.x86_64.qcow2
image: rhel-guest-image-6.5-20131220.3.x86_64.qcow2
file format: qcow2
virtual size: 150G (161061273600 bytes)
disk size: 439M
cluster_size: 65536
6. fdisk -l

*** This bug has been marked as a duplicate of bug 1045242 ***

Without this, we would have to make workarounds to use this image for deploying openstack compute nodes on. This is what our tests are doing and what we think we should do to test the image.

I have VERIFIED this by uploading rhel-guest-image-6.5-20140522.0.x86_64.qcow2
to Openstack Grizzly and booting VM with different flavors, one of 80G, other with 20G disk:

`--> ssh cloud-user.3.2 
[cloud-user@bar ~]$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        79G  877M   74G   2% /
tmpfs           3,9G     0  3,9G   0% /dev/shm

[cloud-user@bar ~]$  sudo fdisk -l /dev/vda

Disk /dev/vda: 85.9 GB, 85899345920 bytes
255 heads, 63 sectors/track, 10443 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00036382

   Device Boot      Start         End      Blocks   Id  System
/dev/vda1   *           1       10443    83882373+  83  Linux


`--> ssh cloud-user.3.8
[cloud-user@foo ~]$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        20G  866M   18G   5% /
tmpfs           939M     0  939M   0% /dev/shm

 sudo fdisk -l /dev/vda

Disk /dev/vda: 21.5 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00036382

   Device Boot      Start         End      Blocks   Id  System
/dev/vda1   *           1        2610    20963801   83  Linux

*** Bug 1016787 has been marked as a duplicate of this bug. ***

Version:
rhel-guest-image-6.6-20140910.0.x86_64.qcow2

Steps:
1. qemu-img resize $image +10G
2. launch booted image, and check the root partition

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        26G  755M   24G   4% /
tmpfs           246M     0  246M   0% /dev/shm

Verified as above.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2014-1697.html