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ć
