I would like to see this for XenServer implemented. I get around this by
having all my bare bone templates at 100GB...it would be nice not have to
change in the DB, then catch it in from the console to expand before CS
shuts it down.

On Mon, Dec 1, 2014 at 6:30 AM, Nux! <n...@li.nux.ro> wrote:

> Vadim,
>
> Currently the ROOT resize feature is not available for hypervisors other
> than KVM. The developers working with these HVs are not interested in this
> feature a.t.m.
> Feel free to request this feature and stress them out. :)
>
> Based on this feature I now only use 1 template with 1 single partition in
> it mounted as / which cloud-init will expand to maximum during deployment.
> Self-resizing can also be done in Windows quite easily.
> I don't think it's acceptable to tell customer to deal with expanding the
> partition himself, so this is automated.
>
> I do not use swap, but when it is a "must" I use a file based swap (eg
> /var/swap.IMG). You could use another primary storage for swap, but IMHO
> this just complicated things and it's not worth it.
> Generally I try not to use multiple volumes for a VM, it makes life easier.
>
> HTH
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> ----- Original Message -----
> > From: "Vadim Kimlaychuk" <vadim.kimlayc...@elion.ee>
> > To: dev@cloudstack.apache.org
> > Sent: Monday, 1 December, 2014 11:09:24
> > Subject: RE: root resize support in the UI
>
> > Andrija,
> >
> >            You did understand me correctly. I wish that for the customer
> disk offer could
> >            be customizable. And not just for KVM hypervisor.
> Particularly now I am
> >            interested in Xen and VmWare.
> > CS admin should not have set of templates that differs only on root
> partition
> > size.  Swap partition can be (theoretically) located as another DATA
> disk and
> > be re-sizable with existing functionality.
> >            How hard is to achieve such a requirement? Are these
> requirements something
> >            unusual and I should do it other way? For example we say to
> the customer, that
> >            you have unallocated space if you select different size and
> extend partition by
> >            yourself?
> >
> > Vadim.
> >
> > -----Original Message-----
> > From: Andrija Panic [mailto:andrija.pa...@gmail.com]
> > Sent: Monday, December 01, 2014 12:06 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: root resize support in the UI
> >
> > 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ć
>



-- 


Todd Pigram
http://about.me/ToddPigram
www.linkedin.com/in/toddpigram/
@pigram86 on twitter
https://plus.google.com/+ToddPigram86
Mobile - 216-224-5769

Reply via email to