openstack team mailing list archive

[Joshua Harlow <harlowja@xxxxxxxxxxxxx>]

+1 I think cloud-init can do this all in a more correct manner and in a
manner that works across more distributions and file system types in the
long term.

On 3/5/13 5:08 PM, "Scott Moser" <smoser@xxxxxxxxxx> wrote:

>On Wed, 6 Mar 2013, Pádraig Brady wrote:
>
>> On 03/05/2013 02:04 PM, Scott Moser wrote:
>> > On Tue, 5 Mar 2013, Sylvain Bauza wrote:
>> >
>> >> If you look at
>> >> http://www.pixelbeat.org/docs/openstack_libvirt_images/#1361764412,
>>you'll see
>> >> that resize2fs is performed. But there is a caveat with RHEL6 which
>>is Linux
>> >> 2.6 (contrary to Ubuntu 12.04 which is Linux 3.0).
>> >> If you look at "man resize2fs" :
>> >
>> > Please don't do this, or rely on this.  Having the hypervisor do this
>>for
>> > your guest is simply wrong.  Hypervisors should know little to nothing
>> > about the internals of the instances they're launching.
>>
>> Just to point out the alternative for when the VM doesn't
>> have the smarts to resize itself, is to use something like virt-resize:
>> https://blueprints.launchpad.net/nova/+spec/resize-no-raw
>
>
>Using libguestfs is worlds better than having the host "directly" do it.
>But really whats happening here is *still* something with very little
>information mucking with (and possibly breaking) the inside of a disk
>image.  The more we consider that a "bucket of bytes" the better.
>
>If you are using libguestfs, chances are you're using it from your distro,
>and patching it to deal with a new filesystem (or otherwise get the update
>to your hostOS) is still problematic.
>
>Just let/expect the guest do it, and we'll avoid a whole silly game of cat
>and mouse that doesn't even have to be played.
>
>When was the last time you updated your bios on your laptop so you could
>use a new linux filesystem?  That sounds silly, doesn't it.  Having
>openstack reach inside the contents of the disk is just as silly.
>
>One of the major benefits of having cloud-init direct the partition resize
>*and* subsequent filesystem resize is that the user can (in user-data)
>disable this!  (currently the initramfs doesn't take any instruction from
>user-data, so disabling it isn't really a possibility).  perhaps they
>didn't want that extra instance-store space to be part of the root
>filesystem.
>
>If you put that function inside the hypervisor, you either can't do it, of
>you have to expose some silly api-launch parameter of
>"do_not_modify_disk".  It complicates the API and complicates the host.