Vadim, not sure if I understand corrrectly - but you have i.e. 10GB template. you provision new VM with different size i.e. 50GB, and then after the instance is UP and running - there is just 40GB of additional unalocated space inside VM/disk, so admin need to resize partition and resize FS... ?
I have been manually using qemu-img to resize some volumes (update the size inside DB) and then boot VM and do "inside VM" work of resizing stuff... If we only increase disk by qemu-img and update the DB - than no more admin-manual hacks needed - and we have consistent solution, that works across all platforms. And to support resize inside differente OS-es by ACS (partitions and FS) - seems pretty impossible for me, except for basic templates that have 1 partition, and i.e. no swap partition, etc...we loose consistency here completely... On 1 December 2014 at 10:33, Vadim Kimlaychuk <vadim.kimlayc...@elion.ee> wrote: > But that means user can not create desired volume during instance set-up. > If we would like to have, for example, VM with disk offers from 5-100Gb I > need to create dozen of same templates that differ only at root size. > > Vadim. > > -----Original Message----- > From: Andrija Panic [mailto:andrija.pa...@gmail.com] > Sent: Monday, December 01, 2014 11:06 AM > To: dev@cloudstack.apache.org > Subject: Re: root resize support in the UI > > Exactly, there may be more than 1 partion on that 1 drive.. So just > increase disk size, and let administaror handle the "inside VM" job > > On 1 December 2014 at 09:34, Erik Weber <terbol...@gmail.com> wrote: > > > On Mon, Dec 1, 2014 at 9:23 AM, Vadim Kimlaychuk < > > vadim.kimlayc...@elion.ee> > > wrote: > > > > > I have done root partition resize under XenServer exactly as you > > described > > > - resized drive and then using system tools on guest VM like fdisk, > > > lvextend and ext2resize changed the size of the root. It seems that > > drive > > > resize on hypervisor level is all that is needed, because it is far > > > too complicated for hypervisor to be aware of all different types of > > partition > > > layouts and file systems that might exist. Then upper layer (like > > > CS) may take role of implementing different actions according to > > > guest type and file system that have being used for particular > > > guest. While OS type can be taken from template, FS type and > > > partition type is information that is not stored in the database. > Without it implementation is not feasible. > > > > > > > It's not given that you want to resize a partition or which one, just > > because you resize the disk. > > > > Thus it's not feasible to assume that the orchestration layer should > > be capable of doing it. > > > > -- > > Erik > > > > > > -- > > Andrija Panić > -- Andrija Panić