cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrija Panic <andrija.pa...@gmail.com>
Subject Re: root resize support in the UI
Date Mon, 01 Dec 2014 21:16:17 GMT
Matheww, offtopic - keep in mind that hostbill will make milion of computer
offerings and everything, so if you login to cloudstack - you will get lost
- at least per my latest experience with hostbill. Also we were told that
they store credit cards in their database - something you might not want.



On 1 December 2014 at 17:57, Logan Barfield <lbarfield@tqhosting.com> wrote:

> Just chiming in: I un-commented the Root Disk field in the Instance Wizard
> in our 4.4 deployment.  Works fine with KVM / Ceph RBD.
>
> The logic we see is:
> A) If specified size is smaller than template size, throw an alert.
> B) If specified size is larger than template size then deploy root disk
> with specified size.
> C) If nothing is specified (default if the box isn't enabled) then deploy
> root disk with same size as template.
>
> This works with KVM and the RBD resize logic I committed a few months ago.
> I can't speak for how it works with Xen/VMware or other primary storage
> backends.
>
>
> Thank You,
>
> Logan Barfield
> Tranquil Hosting
>
> On Mon, Dec 1, 2014 at 11:34 AM, Matthew Midgett <
> cloudstck@trick-solutions.com.invalid> wrote:
>
> > 1+ from me for XenServer root disk resize for template deployments!
> >
> > I'm going with Nux on the single partition scheme and I want my root disk
> > under 2GB as most all of my deployments are minimal systems. This makes
> the
> > journey from sec storage to primary storage quite a bit faster. I need to
> > deploy and resize and be running in under 60 seconds if possible to keep
> my
> > users from sitting around waiting.
> >
> > I will be using hostbill in front of my ACS and they offer these sliders
> > for choosing how much resources you want. Users really like this and if
> > they deploy my 2gb template I'd like to be able to give them that 50GB
> disk
> > they ask for without using a data disk.
> >
> > If cloud-init can do this then I as a user would develop my templates
> > around the file system layout that it supports. EXT3,EXT4,BTRFS or
> LVM....I
> > honestly don't care for using LVM in a Virtual Machine, it's just one
> more
> > layer of complexity on a disk that doesn’t need to be there. Most all
> Linux
> > file systems can support online resize without LVM so I would consider
> not
> > using it to simplify cloud-init resize.
> >
> > Just my 2cents
> >
> > Matthew Midgett
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Nux! [mailto:nux@li.nux.ro]
> > Sent: Monday, December 01, 2014 7:06 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: root resize support in the UI
> >
> > Andrija,
> >
> > Absolutely, everyone has their own needs.
> >
> > The single partition works best for us (we also implemented it in
> physical
> > dedicated servers - makes p2v and v2p easy!) and it also seems to be the
> > choice of others (official fedora/centos/ubuntu templates are like this
> as
> > well).
> >
> > --
> > Sent from the Delta quadrant using Borg technology!
> >
> > Nux!
> > www.nux.ro
> >
> > ----- Original Message -----
> > > From: "Andrija Panic" <andrija.panic@gmail.com>
> > > To: dev@cloudstack.apache.org
> > > Sent: Monday, 1 December, 2014 11:42:29
> > > Subject: Re: root resize support in the UI
> >
> > > ok, Nux, so you suggest, single partition layout, with some predefined
> > > usage scenario...that is definitively an option for me.
> > > On the other hand, if you have slightly complicated templates - then
> > > the only way I see is to only resize the disk qith qemu-img...(not
> > > going inside VM)...
> > >
> > > So we need to decide on the user-case scenario we find most usefull...
> > >
> > > On 1 December 2014 at 12:30, Nux! <nux@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.Kimlaychuk@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.panic@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.Kimlaychuk@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.panic@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 <terbolous@gmail.com>
> wrote:
> > >> >>
> > >> >> > On Mon, Dec 1, 2014 at 9:23 AM, Vadim Kimlaychuk <
> > >> >> > Vadim.Kimlaychuk@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ć
> > >>
> > >
> > >
> > >
> > > --
> > >
> > > Andrija Panić
> >
> >
>



-- 

Andrija Panić

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message