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 <lbarfi...@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 < > clouds...@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:n...@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.pa...@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! <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ć > > >> > > > > > > > > > > > > -- > > > > > > Andrija Panić > > > > > -- Andrija Panić