[ale] partition size increase, using commandline, while VM running - HowTo ?

[JD]

I read it as "I manually use gparted, but that sucks and I want to script it."

If vboxmanage has already been used to extend the vHDD to be larger
AND
if the partitioning is MBR (not GPT)
AND
if another ISO is booted, (still cannot modify open/active partitions)
THEN sfdisk can be used to resize the partition in a script. It is easiest to to
use gparted to get the size you want, dump the settings with sfdisk and use that
dump-file (about 5-10 lines of text) to recreate the partitioning. Ths issue
here is that we don't have a clue about the current partitioning, so we cannot
point out problems, which are likely. Also, if the source VM vHDD partitioning
changes ... the results can be "bad".

parted has a -s option for scripting - I've never used it for scripting.

Need the boot-info output to help anymore.  We are spitting in the wind without
more data. I suspect he is deleting other partitions included in the VDI before
expanding in gparted. We don't know.


On 03/03/2014 10:46 AM, Lightner, Jeff wrote:
> In his original post he says he DOES resize manually with gparted.  If he can do it with gparted he  should be able to do it with parted instead.
> 
> Oddly enough we're just now working on resizing a disk in MS Hyper-V based RHEL6 guest.   We build all of our stuff in LVM rather than mucking with partitions because it is much more flexible.   We do the following setup for our guests:
> vg00_<hostname>  = 100 GB allocated disk from Hypervisor to the guest to be used only for OS and related (e.g. /, /usr, /var, /tmp, /opt, /boot etc...)
> vg01_<hostname> = Allocated disk from Hypervisor to the guest to be used for applications/databases (e.g. Postgres, MySQL, Oracle, EDI etc...)
> 
> The first disk usually shows up as /dev/sda and it does get partitioned into a /dev/sda1 and /dev/sda2 with one of those being a small partition for /boot and the other being the remainder of the disk we put into the first VG (e.g. VolGroup00) as a single PV.   We then make LVs in that VG for each of the filesystems.  (We like to keep them separate.)
> 
> The second disk usually shows up as /dev/sdb and we use the entire device as the PV for the second VG (e.g. VolGroup01) then create LVs for the necessary filesystems.
> 
> We found that for the second disk after having MS Admins allocate additional space and rebooting we saw the new space in /dev/sdb and were able to just do pvresize to increase the amount of space in the second VG.
> 
> A nice write up similar setup based on SAN attached storage rather than Virtual disks in a guest is at:
> http://earlruby.org/2010/10/increasing-the-size-of-an-lvm-physical-volume-pv-while-running-multipathd-without-rebooting/
> That even includes multipath considerations which can be ignored for VM setups but would be helpful for SAN (which we do on other hosts).
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of JD
> Sent: Monday, March 03, 2014 10:26 AM
> To: Atlanta Linux Enthusiasts
> Subject: Re: [ale] partition size increase, using commandline, while VM running - HowTo ?
> 
> You are absolutely correct, but the limitations imposed don't allow resizing a partition. It is not possible to change the partition size on an actively used, running partition. It is possible to cheat if LVM is used, but using LVM inside a VM ... I doubt that the original vHDD has LVM.
> 
> To really know what is happening, a **boot-info** script run for the vHDD would tell all.
> 
> However ... since we are talking VMs, there are lots of other ways to solve the root issue and avoid the desire to resize any partitions. I'd just create an additional vHDD for my stuff and mount both inside the VM.
> a)"VM team" vHDD
> b) my own vHDD
> Probably mount mine into /opt/ or /var/ ... then I wouldn't need to resize.
> 
> There are probably reasons why this suggestion isn't possible. Narahari's environments are uniquely challenging.
> 
> On 03/03/2014 08:41 AM, Lightner, Jeff wrote:
>> Wasn't the original question about the partition rather than the filesystem?
>>