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ć
