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?
February 20, 2013 at 8:28 pm
Seth, I’m not totally sure what the problem is, but have you looked at virt-resize?
February 20, 2013 at 8:31 pm
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.
February 20, 2013 at 8:42 pm
OK gotcha. I don’t know how these images are constructed, but I guess the solution would be for them to use LVM internally so that you can just live resize the root LV + filesystem using regular commands inside the guest.
virt-resize is, of course, strictly off-line. (http://libguestfs.org/guestfs-faq.1.html#why-doesnt-virt-resize-work-on-the-disk-image-in-place- )
February 20, 2013 at 8:45 pm
I tried the lv trick. I cannot change the partitions AT ALL w/o rebooting. The kernel can’t see the partition changes.
February 21, 2013 at 10:12 am
You might want to look at cloud-utils recently announced on Fedora Cloud SIG list, it contains growpart script.
February 22, 2013 at 3:22 am
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.
February 21, 2013 at 11:11 am
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