12/03/2016

Virtualbox, expanding a rhel vm guest

Oracle virtualbox can assemble a vm from many different types of virtual disk images, raw, vmdk or vdi are examples. Sometimes however a vm guest can grow in its need for disk space and you have to expand the size of its virtual disk. This is a method to do that for RHEL5 as a vm guest on windows 7.


A raw disk is an image of an existing machine taken using something like the # dd command to capture the content of physical disk blocks and pack them into a portable file, usually with the extension .raw

A raw disk can be converted into a vmdk (a popular virtual disk format with VMware) using many different tools, one is the fully graphical windows tool from StarWind software.

It can be used as a vmdk for some time as part of a vm created using the virtual machine manager that comes with Oracles Virtualbox software. Then the vmdk virtual disk can fill up.

To get more disk space several concepts must be addressed.

First the outside pseudo-physical container needs to be enlarged.

Virtualbox tools do not support enlarging a vmdk file format, they do support enlarging its native .vdi file format. And the Virtualbox tools can "clone" or simultaneoulsy "copy and convert" from a .vmdk file format to a .vdi file format using the Virtualbox Media Manager menu.

 
Then the commandline version of the Virtualbox tools VirtualboxManager can be used to ["resize"] the .vdi to a larger version. The "resize" argument is the final disk size, so it should be larger than the current size



Once this is done.

0%... 10%... 20%... 30%... 40%... 50%... 60%... 70%... 80%... 90%... 100%

The RHEL5 vm guest inside the image needs to be re-partitioned. Current tools for RHEL5 cannot repartition an installed instance in a vm guest. So a graphical disk partitioner, which is aware of  LVM2 disk partitions is downloaded as a bootable .iso image and attached to the RHEL5 vm guest using the Virtualbox virtual machine tools and booted.





Gparted is semi-intuitive, first the existing partitions are "recognized" and displayed with a color coded legend. Its important that any re-partioner properly identifies and "recognizes" the existing partitions so they are not accidently damaged or erased during the re-partitioning procedure. RHEL5 vm guests typically have a tiny ext2 /boot partition, and a larger LVM2 partion. called a "VolumeGroup", inside are two "smaller, but still very large" volume group - "logical" partitions.



The purpose of the VolumeGroup is so that the upper partitions can "float" or continue to exist while switching out and manipulating or "maintaining" storage disks underneath. A single MBR partition can be use, a single physical disk can be used, or multiple disks - as in a RAID configuration. Failed disks can be swapped in/out and replaced, more disks can be added to enlarge a volume group or even removed to shrink the volume group. -- The "floating" logical paritions "above" the LVM2 partition are completely unaware of the lower "volume group" activities.

In this case we use the Gparted to "resize" the VolumeGroup to make room for enlarging the logical partitions "floating" above the LVM2 partition. GParted does not display the "logical volumes" within the LVM2 Volgroup partition, these have to be manipulated using tools from within the vm guest after it is booted.

Gparted works on the principal of "describe what you want to do" as a series of steps, then "activate" or "apply". This gives you the chance to design how you want the final arrangement of LVM2 partitions and volume groups laid are out and then "commit" the changes to actual disk hardware.
Originally smaller hard disks used a scheme called MBR (master boot record) with tiny fields for describing the partitions on disk. This predated LVM2 (logical volume manager v2) and hard disk sizes continued to grow larger. So large, that describing their size would no longer fit in the tiny MBR "partition size" number fields. So hard disks began being "described" with a new scheme called GPT, which had larger number fields, larger partitions could fit in the new GPT number fields.. but old partitioning software would sometimes see the hard disk as "blank" or "empty" and inadvertently wipe the disks of existing information (this was bad). So new GPT schemes tend to hybridize "both" designs and throw a phoney or "fake" MBR at the top of the drive and "real" GPT  partition records further into the disk. The "fake" MBR partition records  simply say [This Disk "Unclean".. fully used.. Don't Touch Me!]. -- That way older MBR software will generally refuse to work with the disk until the user takes extra steps to destroy their data themselves [first]... they were warned.
Gparted understands GPT formatted disks, which has become the norm. Linux however is started with a bootloader which is ancient and only understands MBR formatted disks, so it has one MBR style partition at the shallow end of the disk, way at the Top; a tiny partition normally mounted to /boot and that is the ext2 partition at the top of the disk.

The second MBR (or first GPT "sized" partition) is the singular "volume group" used by LVM2 to support - or "float"- the two "logical paritions" inside of it, [swap] and [/ (root)] - we are trying to enlarge the second logical partition inside the second MBR "fake"partition which is actually a GPT partition backing the singular volume group.

I like to think of LVM2 partitions as "logical data volume Islands in the Sky".. hello Stratos
Gparted is used to mount and see all that is going on. The Virtualbox machine manager tools already resized the .vdi disk image to a larger size. Gparted is used to enlarge the second MBR, GPT partition supporting the LVM2 volume group. Gparted allows you to select the GPT or volume group partition and drag it to resize it to use all of the newly available virtual disk space. Then the proposed changes are committed to disk with [Apply].



Shutdown and unmount the Gparted .iso from the virtual machine.

Boot the vm guest, start the gui [logical volume] manager tool from the gnome administrative menu. It should see the volume group  the [/ (root)] "file system" resides in.. has new space available.. drag to resize and commit the changes.



Blue Logical Partitions - red shows blocks in LVM2 making up selected Blue Logical Partition



Logical Volume "00" is the / (root)  filesystem - Edit allows "adding" blocks to grow in Size

This gui tool also simultaneously "adjusts" the filesystem and formats the new blocks [without] "destroying" the data on the existing blocks of the Logical Partition, and "notifies" the operating system.. so that the new filespace is immediately available to use... without a reboot.