Thanks for Scott, Padraig, Juerg. I have the whole image of this feature. But, who knows what's the implementation in AWS cloud when using RHEL OS?
On Wed, Mar 6, 2013 at 9:15 AM, Joshua Harlow <harlo...@yahoo-inc.com>wrote: > +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" <smo...@ubuntu.com> 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. > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > -- Lei Zhang Blog: http://jeffrey4l.github.com twitter/weibo: @jeffrey4l
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp