(In reply to Perry Myers from comment #0)
> Description of problem:
> The RHEL guest images (qcow2) contain a root fs that is only 6GB in size. 
> This is fairly small.  We should make the root fs larger (20GB?  50GB?) 
> Increasing the size of the rootfs should not affect the qcow2 compressed
> image size, but it will allow more versatile use of the images
> 
> Specifically... the 6GB size of the rootfs makes it impossible to install
> Red Hat OpenStack 4.0, since Ceilometer requires mongodb which requires at
> least 3+ GB of disk space free.

Perry,

While testing this image, I noticed that the hard drive size needed for the rhel6.4 cloud image was significantly smaller.
As a result of that I couldn't[1] boot an instance using tiny, small or medium flavors.
I had to either use a large flavor or create a custome flavor on my own.

I see that the rootfs occupies a small portion of it. Yet I understand the need for some space for software on top of that image.
My question is: Is there a solution for that manner? using the large flavor consume a lot of RAM, and a custome made flavor is not always a preffered solution. 

[1] ERROR returned from nova: "InstanceTypeDiskTooSmall: Instance type's disk is too small for requested image" see http://pastebin.test.redhat.com/183539

(In reply to Nir Magnezi from comment #4)
> (In reply to Perry Myers from comment #0)
> > Description of problem:
> > The RHEL guest images (qcow2) contain a root fs that is only 6GB in size. 
> > This is fairly small.  We should make the root fs larger (20GB?  50GB?) 
> > Increasing the size of the rootfs should not affect the qcow2 compressed
> > image size, but it will allow more versatile use of the images
> > 
> > Specifically... the 6GB size of the rootfs makes it impossible to install
> > Red Hat OpenStack 4.0, since Ceilometer requires mongodb which requires at
> > least 3+ GB of disk space free.
> 
> Perry,
> 
> While testing this image, I noticed that the hard drive size needed for the
> rhel6.4 cloud image was significantly smaller.
> As a result of that I couldn't[1] boot an instance using tiny, small or
> medium flavors.
> I had to either use a large flavor or create a custome flavor on my own.
> 
> I see that the rootfs occupies a small portion of it. Yet I understand the
> need for some space for software on top of that image.
> My question is: Is there a solution for that manner? using the large flavor
> consume a lot of RAM, and a custome made flavor is not always a preffered
> solution. 
> 
> [1] ERROR returned from nova: "InstanceTypeDiskTooSmall: Instance type's
> disk is too small for requested image" see
> http://pastebin.test.redhat.com/183539

Interesting.  I didn't think about the flavors in conjunction with this, because the expansion of the rootfs from 6GB to 50GB doesn't mean that that amount of space is actually _used_ (since the image is shipped in qcow2 form)

But from a Nova perspective, the flavors would definitely take the rootfs size into account and refuse to launch.  That means that expanding the size of the base image by default does have a negative ramification.

Russell, any advice here from a Nova perspective?  Do we need to really ship images with the smallest possible rootfs size so that they fit into micro flavors, and then require users to manually resize them after download if they want a larger rootfs size?

Will Nova expand the rootfs dynamically if you launch an image with a 6GB rootfs using a larger flavor type?

(In reply to Perry Myers from comment #5)
> (In reply to Nir Magnezi from comment #4)
> > (In reply to Perry Myers from comment #0)
> > > Description of problem:
> > > The RHEL guest images (qcow2) contain a root fs that is only 6GB in size. 
> > > This is fairly small.  We should make the root fs larger (20GB?  50GB?) 
> > > Increasing the size of the rootfs should not affect the qcow2 compressed
> > > image size, but it will allow more versatile use of the images
> > > 
> > > Specifically... the 6GB size of the rootfs makes it impossible to install
> > > Red Hat OpenStack 4.0, since Ceilometer requires mongodb which requires at
> > > least 3+ GB of disk space free.
> > 
> > Perry,
> > 
> > While testing this image, I noticed that the hard drive size needed for the
> > rhel6.4 cloud image was significantly smaller.
> > As a result of that I couldn't[1] boot an instance using tiny, small or
> > medium flavors.
> > I had to either use a large flavor or create a custome flavor on my own.
> > 
> > I see that the rootfs occupies a small portion of it. Yet I understand the
> > need for some space for software on top of that image.
> > My question is: Is there a solution for that manner? using the large flavor
> > consume a lot of RAM, and a custome made flavor is not always a preffered
> > solution. 
> > 
> > [1] ERROR returned from nova: "InstanceTypeDiskTooSmall: Instance type's
> > disk is too small for requested image" see
> > http://pastebin.test.redhat.com/183539
> 
> Interesting.  I didn't think about the flavors in conjunction with this,
> because the expansion of the rootfs from 6GB to 50GB doesn't mean that that
> amount of space is actually _used_ (since the image is shipped in qcow2 form)

Yeah, it's not going to work.

> But from a Nova perspective, the flavors would definitely take the rootfs
> size into account and refuse to launch.  That means that expanding the size
> of the base image by default does have a negative ramification.
> 
> Russell, any advice here from a Nova perspective?  Do we need to really ship
> images with the smallest possible rootfs size so that they fit into micro
> flavors, and then require users to manually resize them after download if
> they want a larger rootfs size?

I would ship the image with a minimal rootfs size.

> Will Nova expand the rootfs dynamically if you launch an image with a 6GB
> rootfs using a larger flavor type?

Nova will not expand the filesystem, but it will put it on a disk of the size the flavor specifies.  It's up to you to resize the filesystem.  cloud-init has some support for doing this, though I haven't tried it with RHEL.

http://docs.openstack.org/image-guide/content/ch_openstack_images.html#support-resizing

My recommendation would be to leave the image as-is, and look at making sure we can support resizing as discussed in the docs above.

(In reply to Russell Bryant from comment #6)
> My recommendation would be to leave the image as-is, and look at making sure
> we can support resizing as discussed in the docs above.

Right, the problem is that as of right now, the cloud-init based image resizing does not work correctly due to bug # 1016787

jboggs, it looks like due to this unforeseen consequence of resizing the root partition in the base image, that we may have to roll back this change and release the guest-image with the other bug fixes for this update and not this one.

We'll just have to provide a Release Note that explains how to manually resize the image using a tool like virt-resize as a short term solution until we can resolve bug # 1016787

Recap of discussion with rbryant, jboggs and lhohberger.

The required disk sizes for the default flavors in Havana and onward are:

Tiny: 1GB, Small 20GB, Medium 40GB

50GB will not work on anything but Large+

Tiny is not an option, we cannot squeeze the RHEL 6 Guest Image into a space that small.

Therefore we will target 15GB rootfs size, which will give us enough space for reasonable usage and will fit into Small and Medium.

This should be large enough to accomodate many use cases, and in cases where it does not, manual resizing using a tool like virt-resize can be done.

This bug is targeted to RHEL 6.6, so we'll continue using it for 6.6 and just retarget the size to be 15GB.  But we will need to reclone this bug to 5.5.z so that we can push out an updated Guest Image with the size dropped from 50GB to 15GB

[root@dhcp-8-247 ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        15G  869M   14G   7% /
tmpfs           246M     0  246M   0% /dev/shm


Disk /dev/sda: 53.7 GB, 53687091200 bytes
255 heads, 63 sectors/track, 6527 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: 0x0003df0c

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        1959    15728640   83  Linux

Please ignore above comment, related test resut for 6.5.z build has been updated to bug1052463#c6 & #c7.

Addition to above:

Pre version: rhel-guest-image-6.5-20131220.3.x86_64.qcow2
Current version: rhel-guest-image-6.5-20140113.1.x86_64.qcow2

Problem: 50GB will not work on anything but Large+ and need more than 6G free space for reasonable usage

Pre version:
[root@localhost ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        48G  885M   44G   2% /
tmpfs           246M     0  246M   0% /dev/shm

Cur version:
[root@dhcp-8-247 ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        15G  869M   14G   7% /
tmpfs           246M     0  246M   0% /dev/shm

The information above verified the rootfs size dropped from 50G to 15G.
Free space is larger than 6G.

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

why is this in POST so long? It is getting confusing, especially when I have created quite conflicting  BZ#1100959.

I would closed this as a NOTABUG because of the BZ#1100959, what do you guys think?

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

Now the root partition size is 16G as required.

Verified.

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