Be careful when working the commands in this article as they have the potential to cause a lot of damage to your data. If you are working with virtual machines make sure you take a snapshot of your virtual machine beforehand, or otherwise have some other form of up to date backup before proceeding. Note that a snapshot must not be taken until after the virtual disk has been increased, otherwise you will not be able to increase it. It could also be worth cloning the virtual machine first and testing out this method on the clone.
As this method focuses on working with LVM, we will first confirm that our partition type is actually Linux LVM by running the below command.
[root@primdb ~]# fdisk -l
Disk /dev/sda: 107.4 GB, 107374182400 bytes, 209715200 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00072c0d
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 2099199 1048576 83 Linux
/dev/sda2 2099200 104857599 51379200 8e Linux LVM
Disk /dev/mapper/ol-root: 48.4 GB, 48444211200 bytes, 94617600 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mapper/ol-swap: 4160 MB, 4160749568 bytes, 8126464 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytesPartition the new disk space
I am working with is /dev/sda, so we use fdisk to create a new primary partition to make use of the new expanded disk space.
Note that we do not have 4 primary partitions already in place, making this method possible.
root@primdb ~]# fdisk /dev/sda
Command (m for help): n
Partition type:
p primary (2 primary, 0 extended, 2 free)
e extended
Select (default p):
Using default response p
Partition number (3,4, default 3):
First sector (104857600-209715199, default 104857600):
Using default value 104857600
Last sector, +sectors or +size{K,M,G} (104857600-209715199, default 209715199):
Using default value 209715199
Partition 3 of type Linux and of size 50 GiB is set
Command (m for help): t
Partition number (1-3, default 3):
Hex code (type L to list all codes): 8e
Changed type of partition 'Linux' to 'Linux LVM'
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table. The new table will be used at
the next reboot or after you run partprobe(8) or kpartx(8)
Syncing disks.You will see a warning which basically means in order to use the new table with the changes a system reboot is required. If you can not see the new partition using “fdisk -l” you may be able to run “partprobe -s” to rescan the partitions. In my test I did not require either of those things at this stage (I do a reboot later on), straight after pressing ‘w’ in fdisk I was able to see the new /dev/sda3 partition of my 10gb of space as displayed in the below image.
For CentOS/RHEL run a “partx -a /dev/sda3” to avoid rebooting later on.
[root@primdb ~]# fdisk -l
Disk /dev/sda: 107.4 GB, 107374182400 bytes, 209715200 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00072c0d
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 2099199 1048576 83 Linux
/dev/sda2 2099200 104857599 51379200 8e Linux LVM
/dev/sda3 104857600 209715199 52428800 8e Linux LVM
Disk /dev/mapper/ol-root: 48.4 GB, 48444211200 bytes, 94617600 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mapper/ol-swap: 4160 MB, 4160749568 bytes, 8126464 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytesThat’s all for partitioning, we now have a new partition which is making use of the previously unallocated disk space from the increase in VMware.
Increasing the logical volume
We use the pvcreate command which creates a physical volume for later use by the logical volume manager (LVM). In this case the physical volume will be our new /dev/sda3 partition.
root@primdb ~]# pvcreate /dev/sda3
Physical volume "/dev/sda3" successfully created.Next we need to confirm the name of the current volume group using the vgdisplay command. The name will vary depending on your setup, for me it is the name of my test server. vgdisplay provides lots of information on the volume group, I have only shown the name and the current size of it for this example.
[root@primdb ~]# vgdisplay
--- Volume group ---
VG Name ol
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 8
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 <49.00 GiB
PE Size 4.00 MiB
Total PE 12543
Alloc PE / Size 12542 / 48.99 GiB
Free PE / Size 1 / 4.00 MiB
VG UUID bosKve-k2Xe-hjEJ-fiy1-CkHF-IXRj-D1lw2I
--- VG Name ol
--- VG Size <49.00 GiBNow we extend the ‘Mega’ volume group by adding in the physical volume of /dev/sda3 which we created using the pvcreate command earlier.
root@primdb ~]# vgextend ol /dev/sda3
Volume group "ol" successfully extendedUsing the pvscan command we scan all disks for physical volumes, this should confirm the original /dev/sda5 partition and the newly created physical volume /dev/sda3
[root@primdb ~]# pvscan
PV /dev/sda2 VG ol lvm2 [<49.00 GiB / 4.00 MiB free]
PV /dev/sda3 VG ol lvm2 [<50.00 GiB / <50.00 GiB free]
Total: 2 [98.99 GiB] / in use: 2 [98.99 GiB] / in no VG: 0 [0 ]Next we need to increase the logical volume (rather than the physical volume) which basically means we will be taking our original logical volume and extending it over our new partition/physical volume of /dev/sda3.
Firstly confirm the path of the logical volume using lvdisplay. This path name will vary depending on your setup.
root@primdb ~]# lvdisplay
--- Logical volume ---
LV Path /dev/ol/root
LV Name root
VG Name ol
LV UUID FxlYVt-PeoE-IiIh-3TXE-JIgJ-qI63-ZXYsu3
LV Write Access read/write
LV Creation host, time localhost.localdomain, 2022-03-06 14:28:53 +0300
LV Status available
# open 1
LV Size <45.12 GiB
Current LE 11550
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 8192
Block device 252:0
***LV Path /dev/ol/rootLogical volume is then extended using the lvextend command.
[root@primdb ~]# lvextend /dev/ol/root /dev/sda3
Size of logical volume ol/root changed from <45.12 GiB (11550 extents) to 95.11 GiB (24349 extents).
Logical volume ol/root successfully resized.There is then one final step which is to resize the file system so that it can take advantage of this additional space, this is done using the resize2fs command for ext based file systems. Note that this may take some time to complete, it took about 10 seconds for my additional space.
[root@primdb ~]# resize2fs /dev/ol/root
Alternatively if you’re running the XFS file system (default as of RedHat/CentOS 7) you can grow the file system with the following command:
root@primdb ~]# xfs_growfs /dev/ol/root
meta-data=/dev/mapper/ol-root isize=256 agcount=4, agsize=2956800 blks
= sectsz=512 attr=2, projid32bit=1
= crc=0 finobt=0, sparse=0, rmapbt=0
= reflink=0
data = bsize=4096 blocks=11827200, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=5775, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 11827200 to 24933376
Bir yanıt yazın