1 step forward 2 steps back? openstack and img creation issues

February 20, 2013

dealing with image creation in all clouds is completely full of suck. I’d more or less come to terms on it with euca but now I’m trying to do the same thing with openstack and encountering some super-duper happy fun times.

I have a rhel6 img which works and boots – it is qcow2 based so it handles kernel updates, etc properly, yay. However it handles resizing  the / filesystem exactly not at all.

If I make the rhel6 img an ami and upload kernel/ramdisk – it’ll resize (well dump it out) into a large filesystem – no problem – but it handles kernel updates not at all.

I would like to have both, I think I deserve to have both, i’ll be damned if any of my testing comes up with both. I’ve done a fair amount of googling and LOTS of things I’ve found say that the qcow2 or raw img should just work in either openstack essex or folsom but I am not having that experience.

Anyone have a suggestion?

About these ads

7 Responses to “1 step forward 2 steps back? openstack and img creation issues”

  1. rich Says:

    Seth, I’m not totally sure what the problem is, but have you looked at virt-resize?

    • skvidal Says:

      This is IN the instance – not before. Remember – these instances are inside qemu/kvm – but they are being spawned by openstack. The resize of the image it is making for the instance has already happened before the instance boots.

      The problem is the instance is booted. We need to grow the mounted/running / to fill out the rest of the space.

      I can do this if I reboot the instance but that’s kinda an odd requrement all things considered.

  2. apevec Says:

    You might want to look at cloud-utils recently announced on Fedora Cloud SIG list, it contains growpart script.

    • skvidal Says:

      apevec: we have looked at it – the issue is still – we need to do the repartitioning in the initramdisk otherwise we have to reboot.

      See my next post on the subject.


  3. OpenStack could use virt-resize –expand on the image before it’s booted. One caveat with that is that a partition needs to be specified. It would benefit from some introspection to select the root or largest file system and expand everything under that.

    Anyway these are on the TODO list:
    https://blueprints.launchpad.net/nova/+spec/resize-no-raw
    https://bugzilla.redhat.com/show_bug.cgi?id=891350


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: