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ć

Reply via email to