There are potential issues that you can encounter when working with Server 2012 virtual machines, especially around resizing drives. Using vSphere 5.1, ESXi 5.1 host, and VMware tools with Red Hat Enterprise Linux 6.4, I wanted to start a discussion on how to resize drives in Linux.

Using a simple example

When I resized Server 2012 drives in VMware, I chose to work with a 40 GB base disk. I'm going to go with a 20 GB drive this time around.

I did a pretty basic install of RHEL, but most importantly, I chose to set up my system using Linux logical volumes for my disks, which is the default. I had to customize my setup because I chose to define two logical volumes for / and /home, and placed them in a single volume group.

For someone new to Linux, or that hasn't worked with other logical volume managers, this terminology might be completely new to you. Describing the Linux logical volume manager is beyond the scope of this post, but I hope everyone is able to follow along and maybe learn something new.

When learning something new, I definitely like to try to get comfortable with a visual representation when possible, and to show things here. I wouldn't have a problem with going through everything at the command line, but I wanted to try to show things somewhat visually.

I actually needed to dig around a bit to find a graphical user interface (GUI) that would allow me to view logical volumes in RHEL. Again, just for the purpose of showing something, I decided to install the "system-config-lvm-1.1.12-15.el6.noarch.rpm" package from the RHEL DVD. This provides a GUI to Linux logical volume. The package is still included in the base DVD, but based on some research, is now no longer maintained.

Once I fire up the Logical Volume Manager (LVM) GUI, I see the following graphical representation of my current system, which shows the single volume group, and three logical volumes: /, /home and swap.

I will also increase the size of the single virtual disk by 5 GB (up to 25 GB). This is a pretty simple exercise and I covered how to do this briefly in an earlier post.

Once I did that, if I immediately go to the LVM GUI, I don't see any difference. Even if I re-open LVM or go to “View” and “Reload,” I still don't see any changes to the virtual disk inside the RHEL VM. I could just reboot the system and that should fix the problem, but rebooting isn't always an option. Furthermore, if I can resize in Windows Server 2012 without a reboot, I'd like to see RHEL be able to do the same thing.

So, I'm going to use the fdisk command to see what the disk layout looks like in RHEL.

Without getting into the whole "bits vs. bytes" thing, I can see that /dev/sda is “21.5GB” which is my 20GB disk I originally created.

Now, I'm going to use some fancy magic to force RHEL to rescan for SCSI disks. Just by writing a ‘1' to a special file, this will force RHEL to rescan.

There's no guarantee that the “2:0:0:0” path will be the same on every system, so this is something you will have to review once you've checked what's in your /sys/class/scsi_disk directory.

Now, if I run fdisk again, I now see that my initial disk is now 26.8 GB, which means RHEL now sees the full-size 25 GB disk that I resized.

If I go back to LVM now, I will see a new “Unpartioned space” section show up.

From this point, there's two ways one can go ahead and use this extra space. Without introducing even more LVM terminology, I'm going to go with the option that the Linux community seems to agree on being the “safer” way to do things.

Creating a new partition

Next, what I'm going to do is set up this new unpartioned space by creating an entry in the partition table for it. In this case, I'm going to define it as a primary partition and give it the next available number which is “3” in this case.

Above, one very important thing to do is to set the partition type to “8e” which is “Linux LVM” as shown above. If you miss this step, the process of adding the partition to LVM could cause major system problems, so be careful to not miss this important step in this scenario.

The value I used for the “first cylinder” is basically the next available number based on the previous fdisk output that shows that partition #2 ends at cylinder 20480.

The last step after having created a partition and setting the type is to write the changes to the partition table.

Attempting to write the partition table causes a warning message about doing a reboot, but also indicates that running partprobe can be done instead.

Unfortunately, partprobe doesn't work in my case, so I'm going to reboot the system to avoid any issues. I don't want to reboot, but I'm being cautious in this case to make sure I don't cause any corruption.

After a reboot, if I open LVM to check things out, I now see that my un-partitioned space now looks different, and possibly usable.

Volume group modification

Now, if I move on to the next thing, I need to do a few things in LVM to use the new partition. I'm going to go with the command-line for a bit, and try to display some visual information along with the commands I'm running.

First, I'm going to use the command “vgdisplay”, which is like “volume group display.” Based on the options chosen when I installed RHEL, the default volume group is named “vg_rhel6” in this case.

The important thing to note above is the VG Size value of 19.51 GiB. Now, I'm going to use the “vgextend” command (volume group extend) to modify my volume group to use the new partition that I just created.

Just after extending the volume group above, I did another vgdisplay, and how I see the VG Size is now increased to 24.50 GiB.

To see what I've done so far, a peak at LVM shows what I have now.

Above, I see that a new “Unused Space” section is now showing in the logical view of my volume group.

Logical volume modification

Now that I've added more unused space to the volume group, I need to modify my logical volume to use this new space.

I'm going to use the “lvextend” command (logical volume extend) to increase the size. In this case, I'm going to look at extending my / file system first, so I'll modify the underlying logical volume.

Above, I chose to use 4999M instead of 5G because the latter would return an error about not enough space being available. I'm not going to get into the specifics of these small calculations here.

I increased the logical volume above, but you may note that a second “df -h” command returned the same size for /. That's because one more step is required, which is to resize the file system that basically sits on the logical volume, as shown. Once the file system is resized, a final “df -h” now shows that my / is now increased by 5GB basically.

Wait a minute!

If I have a single disk, I wasn't able to resize a volume unless it was at the end of a disk. Linux doesn't have that limitation when using the new LVM (technically known as “LVM2”).

So, with LVM, I can resize a disk no matter where it logically sits. For example, I can also resize /home, which was at the end of my disk before I resized it.

Again, I can resize a file system no matter where it seems to be on the disk.

Adding a second disk

Because of how LVM works, the earlier steps I would go through would also apply to how I would work with a second VMware “hard disk” added to the virtual machine. Instead of being seen as /dev/sda, it would be seen as /dev/sdb. I would still need to create a partition on it, extend the volume group, extend the logical volume and finally do another resize2fs.

Lesson learned

What I've gone through here with RHEL, is slightly different from what I encountered with Windows Server 2012.

I had limitations with Windows Server 2012 that no longer exist in RHEL, but remember that this is dependent on using LVM, otherwise, there are limitations that impact disk resizing, similar to the issues discussed in the Windows Server 2012 post, and I'll cover those issues in a future post.

The important thing to consider here, above all else, is the importance of using LVM. You may want to stick with using a multi-disk setup, by considering a volume group per disk for example, but it is optional in this case.

It's difficult to give the same clear guidance on best practices with RHEL as it was with Windows Server 2012, because RHEL with LVM is so much more flexible.

Remember, planning ahead can save a lot of headaches down the road.