While working on a VirtualBox VM, I initially gave it 20GB to work with, in a dynamically allocated disk image (VDI). Soon I discovered that I only really had 17GB of space allocated to the root partition and that a large database operation that I wanted to do on this VM used up all available space. So, I needed to increase the disk space allocated to the VM by VirtualBox, and ensure too that the guest OS (Rocky Linux) was aware of the space.
Increasing the size of the disk in VirtualBox 7 was easy enough. With guest stopped, I could access the disk properties in 'Tools' and change the size to 40GB from 20GB. However, it was not sufficient to just restart the VM. Instead, I needed to download a Live CD which I could insert into the virtual CD drive of the guest with the proper tools used to re-partition the guest OS. For this task, I used the Gnome Partition Editor, more commonly known as 'gparted'. gparted-live-1.5.0-6-i686.iso (470MB). The strange part was that even after resizing the guest hard drive, the partitions still were not using the full space available. In the lsblk output below, you can see that sda2 has 39GB available, but that the root volume is only 17GB on disk.
lsblk -o name,type,fstype,mountpoint,size NAME TYPE FSTYPE MOUNTPOINT SIZE sda disk 40G ├─sda1 part xfs /boot 1G └─sda2 part LVM2_member 39G ├─rl-root lvm xfs / 17G └─rl-swap lvm swap [SWAP] 2G sr0 rom 1024M
Using df -h, it is clear that the OS thinks it is out of space
[userx@localhost ~]$ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.8G 0 3.8G 0% /dev tmpfs 3.8G 540K 3.8G 1% /dev/shm tmpfs 3.8G 9.3M 3.8G 1% /run tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup /dev/mapper/rl-root 17G 17G 62M 100% / /dev/sda1 1014M 363M 652M 36% /boot tmpfs 769M 32K 769M 1% /run/user/1000
The Logical Volume System (LVS) shows
sudo lvs --all LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert root rl -wi-ao---- <17.00g swap rl -wi-ao---- 2.00g
Taking a look at the Volume Groups, we see that there is one named 'rl' (short for Rocky Linux, and named by our VirtualBox setup when we named the VM 'rl'):
sudo vgs VG #PV #LV #SN Attr VSize VFree rl 1 2 0 wz--n- <39.00g 20.00g
vgdisplay gives you the most detail as to what is available
# vgdisplay --- Volume group --- VG Name rl System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 4 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VG Size <39.00 GiB PE Size 4.00 MiB Total PE 9983 Alloc PE / Size 4863 / <19.00 GiB Free PE / Size 5120 / 20.00 GiB VG UUID FSoO96-K50l-S1UC-zCLM-y6fz-JRWg-DBKdTP
Test the resize using the --test option
lvextend --test --extents +100%FREE --resizefs /dev/rl/root
Then do it for real without the --test option.
Upon success - which was immediate in my case - I was able to see the newly available space with df and didn't need to do anything further like xfs_growfs
# df -Th Filesystem Type Size Used Avail Use% Mounted on devtmpfs devtmpfs 3.8G 0 3.8G 0% /dev tmpfs tmpfs 3.8G 540K 3.8G 1% /dev/shm tmpfs tmpfs 3.8G 9.3M 3.8G 1% /run tmpfs tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup /dev/mapper/rl-root xfs 37G 18G 20G 47% / /dev/sda1 xfs 1014M 363M 652M 36% /boot tmpfs tmpfs 769M 32K 769M 1% /run/user/1000
Reference
- https://docs.rockylinux.org/books/admin_guide/07-file-systems/
- https://www.virtualbox.org/manual/ch08.html#vboxmanage-modifymedium (note: I didn't use VBoxManage, I just used the 'Tools' in the VirtualBox GUI)