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ć
