Bill Lumbergh: Milt, we're gonna need to go ahead and move you downstairs into storage B. We have some new people coming in, and we need all the space we can get. So if you could just go ahead and pack up your stuff and move it down there, that would be terrific, OK?

Milton Waddams: Excuse me, I believe you have my stapler.

From the film Office Space per https://www.imdb.com/title/tt0151804/quotes/

Photo by Markus Spiske: https://www.pexels.com/photo/people-space-apple-industry-2644597/

Table of Contents:

Virtual Media Manager

Resizing the Red Hat Guest

gparted

lvextend and xfs_grow

Lessons Learned

Credits

This turned out to be an epic fail! I am cutting my losses after a few days! I try to learn from both my successes and failures so I am posting anyway.

Some unknown person said, "Disk space is like money: you can never have too much." I recently had to expand the size of my Red Hat Enterprise Linux (RHEL) 8 VirtualBox virtual hard drive.

I found this to be harder than I thought that it needed to be so this guide is the result. I did this on a Windows 10 host. Furthermore, I did not achieve success!

Virtual Media Manager

Around version 6 of VirtualBox (or thereabouts) introduced a Virtual Media Manager into their Graphical user interface (GUI). Previously it was only possible to expand VirtualBox disks from the command line. To do so, navigate to File > Tools > Virtual Media Manager. On my machine the submenus looks like the figure:

There is a difficulty though. If you use snapshots (I recommend doing so -- see https://docs.oracle.com/en/virtualization/virtualbox/6.0/user/snapshots.html

and my website) you need to be aware that you need to be careful that you are resizing the correct snapshot. See Stack Exchange: https://unix.stackexchange.com/questions/174571/gparted-doesnt-recognize-my-newly-resized-vdi.

I have been using this instance for around 4 months and my snapshots look like this:

My RHEL VirtualBox snapshots after about 4 months

The Virtual Media Manager view looks like this:

Snapshot details. I want to expand the last snapshot (circled in figure)

I want to expand this snapshot to around 40 gigabytes. So I drag the size bar to the appropriate amount and click “Apply.” See the figure:

Note that it is not possible to shrink virtual drives in VirtualBox.

That’s it for the Host Operating System (Virtual machine - Wikipedia)! Now we need to resize it inside the Red Hat Guest (What is a Guest Operating System (Guest OS)? - Definition from Techopedia).

Resizing the Red Hat Guest

This is where I failed. :~( Note that I rebooted after each of these steps:

Resizing with gparted.
Resizing with lvextend.
Resizing with xfs_growfs. This where where I failed.

Boot into the Red Hat 8 VM and log in. Verify that the VM still needs stuff done to it by running:

df -hT

The df command reports disk space usage and the -h option makes the output human readable and -T asks it to print the filesystem type.

gparted

I used the GNOME partition editor — see https://en.wikipedia.org/wiki/Gparted — as my first resize step. It is well documented on the website https://gparted.org/index.php and I think most Linux system administrators are aware of how to use it.

To install gparted on Red Hat enter:

sudo dnf install gparted

To run gparted enter:

sudo gparted

A screen should come up showing the unallocated partitions:

gparted GUI showing allocated (yellow) vs unallocated (grey) space

If your screen does not look similar to this then you might have more than one disk installed. Try changing the selected drive in gparted.

First click on the partition you would like to edit. Mine is /dev/sda2 in the figure. Then, navigate to Partition > Resize/Move in the gparted GUI. Drag the yellow bar all the way to the left if you want to use all the space. See the figure for context:

Figure showing the gparted resizing dialog

To apply the changes click the green check mark near the top middle portion of the screen. Then

REBOOT THE VM. I don’t know that that is strictly necessary—that’s what I did.

After that I thought I was done. Silly me, there were still two steps to go! AND I BOTCHED THE LAST ONE!

lvextend and xfs_grow

My first clue that something was amok was by running df -hT again and getting some unexpected output:

[mday@localhost ~]$ df -hT

Filesystem Type Size Used Avail Use% Mounted on

devtmpfs devtmpfs 7.4G 0 7.4G 0% /dev

tmpfs tmpfs 7.4G 0 7.4G 0% /dev/shm

tmpfs tmpfs 7.4G 9.4M 7.4G 1% /run

tmpfs tmpfs 7.4G 0 7.4G 0% /sys/fs/cgroup

/dev/mapper/rhel-root xfs 14G 12G 2.1G 85% /

/dev/sda1 xfs 1014M 356M 659M 36% /boot

C_DRIVE vboxsf 944G 489G 456G 52% /media/sf_C_DRIVE

tmpfs tmpfs 1.5G 12K 1.5G 1% /run/user/42

tmpfs tmpfs 1.5G 20K 1.5G 1% /run/user/1000

What the heck? I thought the partition on /dev/mapper/rhel-root was resized to around 40 Gig! Something was fishy. After some internet searching I stumbled across The 'xfs_growfs' command fails on device. - Red Hat Customer Portal. This said that the culprit was https://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux)

Following the instructions on that post I ran the following command:

sudo lvextend -L +20G /dev/mapper/rhel-root
sudo lvextend -L +5G /dev/mapper/rhel-root
sudo lvextend -L +2G /dev/mapper/rhel-root

… and so forth until I used up most of the space.

then I rebooted. Then I ran

sudo xfs_growfs /

Note the xfs_growfs does NOT use /dev/mapper/rhel-root

then I rebooted.

This is where I ran into trouble. After running this command VirtualBox would either run awhile longer and then freeze or freeze immediately with this error:

The I/O cache encountered an error while updating data in medium "ahci-0-0" (rc=VERR_INVALID_PARAMETER). Make sure there is enough free space on the disk and that the disk is working properly. Operation can be resumed afterwards. Error ID: BLKCACHE_IOERR Severity: Non-Fatal Error

I ran through every step of the process (from gparted to xfsgrowfs) every way I could think of about 10 times (tweakng parts of my process every time). Nothing seemed to be working and it failed every time on the xfs_growfs command!

Checking ChatGPT for this error was the last straw:

The error message you encountered indicates an issue with the I/O cache while updating data on the "ahci-0-0" disk medium. The specific error code suggests an invalid parameter was provided, potentially related to the disk space or the disk's functionality.

I just gave up at that point. It was likely a problem that had occurred in the VirtualBox cache system and I was way too far down this rabbit hole.

Lessons Learned

One of the mistakes I made was letting Red Hat do the partitioning for me. That led to the whole Logical Volume Manager fiasco. In the future I will do my own partitioning and use a “physical” (but really virtual) drive. LVM just adds a whole new layer of abstraction which is silly because I’m already using a virtual medium.

Another thing I might try is to use the Extended file system (ext) instead of XFS.

I looked into Kernel-based Virtual Machine (KVM) as alternative to VirtualBox but that would just put a VM inside Windows Subsystem for Linux (WSL) or a similar system since my target host is Windows 10. I am too cheap to use VMware. And I have had performance problems with QEMU before.

I am curious, what would you guys try differently? Leave me suggestions in the comments if you like.