Increase an ext4 filesystem in RHEL 6/CentOS 6

In this post I will demonstrate how to increase an ext4 filesystem in RHEL 6/CentOS 6. This has been covered a million times on the internet, this is my version and really serves as a reminder for myself. If it benefits you then that is a bonus.

My Environment

Let me briefly confirm the environment I am using for this demo.  My server is a VMware VM and the OS is CentOS 6.6, it presently contains 4 virtual disks:

20150611165654

All the virtual disks are in use and the system comprises multiple filesystems. We are going to use the filesystem /var/video to deomonstrate the expansion process, it is presently running low on free space. We will need to transfer data to it but at present there is insufficient space to accommodate this transfer.

The Expansion Process

Please note that if the filesystem being increased is utilized by a high I/O application then it would be wise to stop the application first and then unmount the filesystem before proceeding with the steps below. The increase can be done online but I would always recommend erring on the side of caution, just in case. I would also ensure that you back up the system prior to any disk expansion activity – you can never be too safe.

The process required to increase a filesystem starts at the bottom layer, the Physical Volume layer. It must be increased first and the extra capacity is allocated upwards all the way to the filesystem. The order of which is shown below:

Physical Volumes --> Volume Groups --> Logical Volumes --> Filesystems

So without further ado, let’s crack on with the expansion process.

1. First, let us confirm the information about our filesystem /var/video by running df -h:

[root@lnx-svr-01 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root
                       18G  908M   16G   6% /
tmpfs                 939M     0  939M   0% /dev/shm
/dev/sda1             477M   25M  427M   6% /boot
/dev/mapper/data-music
                      9.8G  4.4G  4.9G  48% /var/music
/dev/mapper/data-video
                      4.8G  4.4G  228M  96% /var/video
/dev/mapper/data-pictures
                      4.8G   10M  4.6G   1% /var/pictures
[root@lnx-svr-01 ~]#

We can see that it has a total capacity of 4.8GB and only has 228MB free. The device that /var/video maps to is /dev/mapper/data-video. We intend to copy 4.4GB of data to /var/video and will need at least another 5GB of capacity in order to meet the capacity requirement. We will therefore increase /var/video by 5GB which will give us a little bit of room left after the data transfer.

2. We must see how the filesystem maps to the underlying disk(s), at this stage we don’t know, so we need to find out more information so let’s take a look at the partition layout by running fdisk -l:

[root@lnx-svr-01 ~]# fdisk -l

Disk /dev/sda: 21.5 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00099a71

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          64      512000   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2              64        2611    20458496   8e  Linux LVM

Disk /dev/sdb: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x2ac771b0

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1         652     5237158+  8e  Linux LVM

Disk /dev/sdc: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xfd839be4

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1        1305    10482381   8e  Linux LVM

Disk /dev/sdd: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x8b19e7ca

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               1         652     5237158+  8e  Linux LVM

Disk /dev/mapper/VolGroup-lv_root: 18.8 GB, 18798870528 bytes
255 heads, 63 sectors/track, 2285 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/VolGroup-lv_swap: 2147 MB, 2147483648 bytes
255 heads, 63 sectors/track, 261 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/data-music: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/data-pictures: 5343 MB, 5343543296 bytes
255 heads, 63 sectors/track, 649 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/data-video: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

[root@lnx-svr-01 ~]#

As you can see from the output above, there are 4 hard disks; /dev/sda/dev/sde. All of them contain a single LVM partition. We also see that /var/video is associated with device /dev/mapper/data-video. We saw this earlier when running the df- h command – we are on the right track.

3. Now run lvs to view a list of Physical Volumes:

[root@lnx-svr-01 ~]# lvs
  LV       VG       Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lv_root  VolGroup -wi-ao---- 17.51g
  lv_swap  VolGroup -wi-ao----  2.00g
  music    data     -wi-ao---- 10.00g
  pictures data     -wi-ao----  4.98g
  video    data     -wi-ao----  5.00g
[root@lnx-svr-01 ~]#

We know that our filesystem /var/video maps to device /dev/mapper/data-video. We see from the output above that our filesystem is Logical Volume (LV) video and it is located within Volume Group (VG) data. This explains the device name; /dev/mapper/datavideo. The table below illustrates this a little clearer for the 3 x Logical Volumes that are located within the Volume Group data:

Device VG LV
/dev/mapper/data-video
/dev/mapper/data-music
/dev/mapper/data-Pictures

4. Run vgs to confirm that there are 3 x Logical Volumes assigned to Volume Group data:

[root@lnx-svr-01 ~]# vgs
  VG       #PV #LV #SN Attr   VSize  VFree
  VolGroup   1   2   0 wz--n- 19.51g    0
  data       3   3   0 wz--n- 19.98g    0
[root@lnx-svr-01 ~]#

Under the LV heading we see 3, representing the 3 x Logical Volumes (music, video & pictures) that are in the Volume Group data. Under the VFree heading we also see that there is no free space within Volume Group data to assign to any of the Logical Volumes including video.

5. We now know that Volume Group data is where the Logical Volume video is located. We need to go one step deeper in the in LVM layer to see what Physical Volumes (PV) sit under the Volume Group data. Run pvs to find out:

[root@lnx-svr-01 ~]# pvs
PV VG Fmt Attr PSize PFree
/dev/sda2 VolGroup lvm2 a-- 19.51g 0
/dev/sdb1 data lvm2 a-- 4.99g 0
/dev/sdc1 data lvm2 a-- 9.99g 0
/dev/sdd1 data lvm2 a-- 4.99g 0
[root@lnx-svr-01 ~]#

From the above we know that Physical Volumes /dev/sdb1, /dev/sdc1 & /dev/sdd1 together make up Volume Group data.

In order to increase the size of Logical Volume video, we need to increase the size of Volume Group data. To increase the size of Volume Group data we have 2 options:

Option 1 – ADD another Physical Volume (another disk) into Volume Group data, then expand it and then expand Logical Volume video.

Option 2 – EXPAND one of the existing Physical Volumes in Volume Group data, then expand it and then expand Logical Volume video.

Which option you choose depends on your situation. If your server is a production server and you want to avoid a reboot then Option 1 is advised. If you want to avoid adding an extra disk to the server and you are happy to accommodate a reboot then Option 2 is advised. I personally prefer Option 2 because in the long run it keeps the system clean and free of lots of disks, which is easier to manager and minimizes mistakes. To elaborate further deserves a post of it’s own and is a conversation for another day. For the purposes of this exercise I will take Option 1 (adding another disk to increase the Volume Group).

6. I therefore add another 5GB disk, in the vSphere Client you can see that the newly added disk is Hard Disk 5:

20150614181018

7. Rescan the bus in order to see the new disks:

[root@lnx-svr-01 ~]# grep mpt /sys/class/scsi_host/host?/proc_name
/sys/class/scsi_host/host2/proc_name:mptsas
[root@lnx-svr-01 ~]# echo "- - -" > /sys/class/scsi_host/host2/scan
[root@lnx-svr-01 ~]#

8. Run fdisk -l to verify it is now visible:

[root@lnx-svr-01 ~]# fdisk -l

Disk /dev/sda: 21.5 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00099a71

Device Boot Start End Blocks Id System
/dev/sda1 * 1 64 512000 83 Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2 64 2611 20458496 8e Linux LVM

Disk /dev/sdb: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x2ac771b0

Device Boot Start End Blocks Id System
/dev/sdb1 1 652 5237158+ 8e Linux LVM

Disk /dev/sdc: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xfd839be4

Device Boot Start End Blocks Id System
/dev/sdc1 1 1305 10482381 8e Linux LVM

Disk /dev/sdd: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x8b19e7ca

Device Boot Start End Blocks Id System
/dev/sdd1 1 652 5237158+ 8e Linux LVM

Disk /dev/mapper/VolGroup-lv_root: 18.8 GB, 18798870528 bytes
255 heads, 63 sectors/track, 2285 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/VolGroup-lv_swap: 2147 MB, 2147483648 bytes
255 heads, 63 sectors/track, 261 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/data-music: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/data-pictures: 5343 MB, 5343543296 bytes
255 heads, 63 sectors/track, 649 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/data-video: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/sde: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

[root@lnx-svr-01 ~]#

As we can see the new disk /dev/sde is visible but contains no partition.

9. Partition it with LVM by running the following commands:

[root@lnx-svr-01 ~]# fdisk /dev/sde
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0x72d22af8.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
switch off the mode (command 'c') and change display units to
sectors (command 'u').

Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-652, default 1):
Using default value 1
Last cylinder, +cylinders or +size{K,M,G} (1-652, default 652):
Using default value 652

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): L

0 Empty 24 NEC DOS 81 Minix / old Lin bf Solaris
1 FAT12 39 Plan 9 82 Linux swap / So c1 DRDOS/sec (FAT-
2 XENIX root 3c PartitionMagic 83 Linux c4 DRDOS/sec (FAT-
3 XENIX usr 40 Venix 80286 84 OS/2 hidden C: c6 DRDOS/sec (FAT-
4 FAT16 <32M 41 PPC PReP Boot 85 Linux extended c7 Syrinx
5 Extended 42 SFS 86 NTFS volume set da Non-FS data
6 FAT16 4d QNX4.x 87 NTFS volume set db CP/M / CTOS / .
7 HPFS/NTFS 4e QNX4.x 2nd part 88 Linux plaintext de Dell Utility
8 AIX 4f QNX4.x 3rd part 8e Linux LVM df BootIt
9 AIX bootable 50 OnTrack DM 93 Amoeba e1 DOS access
a OS/2 Boot Manag 51 OnTrack DM6 Aux 94 Amoeba BBT e3 DOS R/O
b W95 FAT32 52 CP/M 9f BSD/OS e4 SpeedStor
c W95 FAT32 (LBA) 53 OnTrack DM6 Aux a0 IBM Thinkpad hi eb BeOS fs
e W95 FAT16 (LBA) 54 OnTrackDM6 a5 FreeBSD ee GPT
f W95 Ext'd (LBA) 55 EZ-Drive a6 OpenBSD ef EFI (FAT-12/16/
10 OPUS 56 Golden Bow a7 NeXTSTEP f0 Linux/PA-RISC b
11 Hidden FAT12 5c Priam Edisk a8 Darwin UFS f1 SpeedStor
12 Compaq diagnost 61 SpeedStor a9 NetBSD f4 SpeedStor
14 Hidden FAT16 <3 63 GNU HURD or Sys ab Darwin boot f2 DOS secondary
16 Hidden FAT16 64 Novell Netware af HFS / HFS+ fb VMware VMFS
17 Hidden HPFS/NTF 65 Novell Netware b7 BSDI fs fc VMware VMKCORE
18 AST SmartSleep 70 DiskSecure Mult b8 BSDI swap fd Linux raid auto
1b Hidden W95 FAT3 75 PC/IX bb Boot Wizard hid fe LANstep
1c Hidden W95 FAT3 80 Old Minix be Solaris boot ff BBT
1e Hidden W95 FAT1
Hex code (type L to list codes): 8e
Changed system type of partition 1 to 8e (Linux LVM)

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
[root@lnx-svr-01 ~]#

10. Now run fdisk -l /dev/sde to verify that /dev/sde contains an LVM partition:

[root@lnx-svr-01 ~]# fdisk -l /dev/sde

Disk /dev/sde: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x72d22af8

Device Boot Start End Blocks Id System
/dev/sde1 1 652 5237158+ 8e Linux LVM
[root@lnx-svr-01 ~]#

Good news, we can see it does and the partition is /dev/sde1.

11. Next, create a new Physical Volume on /dev/sde1 by running  pvcreate:

[root@lnx-svr-01 ~]# pvcreate /dev/sde1
Physical volume "/dev/sde1" successfully created
[root@lnx-svr-01 ~]#

Then run pvs to see that it is visible in the list of Physical Volumes:

[root@lnx-svr-01 ~]# pvs
PV VG Fmt Attr PSize PFree
/dev/sda2 VolGroup lvm2 a-- 19.51g 0
/dev/sdb1 data lvm2 a-- 4.99g 0
/dev/sdc1 data lvm2 a-- 9.99g 0
/dev/sdd1 data lvm2 a-- 4.99g 0
/dev/sde1 lvm2 --- 4.99g 4.99g
[root@lnx-svr-01 ~]#

We can see that /dev/sde1 is now a Physical Volume but is not assigned to a Volume Group. We must add it to Volume Group data.

12. Extend the Volume Group data to include the newly added Physical Volume /dev/sde1:

[root@lnx-svr-01 ~]# vgextend data /dev/sde1
Volume group "data" successfully extended
[root@lnx-svr-01 ~]#

13. Run pvs again to verify that /dev/sde1 is part of Volume Group data:

[root@lnx-svr-01 ~]# pvs
PV VG Fmt Attr PSize PFree
/dev/sda2 VolGroup lvm2 a-- 19.51g 0
/dev/sdb1 data lvm2 a-- 4.99g 0
/dev/sdc1 data lvm2 a-- 9.99g 0
/dev/sdd1 data lvm2 a-- 4.99g 0
/dev/sde1 data lvm2 a-- 4.99g 4.99g
[root@lnx-svr-01 ~]#

14. Run vgdisplay to confirm that Volume Group data has the extra 5GB of capacity:

[root@lnx-svr-01 ~]# vgdisplay data
--- Volume group ---
VG Name data
System ID
Format lvm2
Metadata Areas 4
Metadata Sequence No 9
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 3
Max PV 0
Cur PV 4
Act PV 4
VG Size 24.97 GiB
PE Size 4.00 MiB
Total PE 6392
Alloc PE / Size 5114 / 19.98 GiB
Free PE / Size 1278 / 4.99 GiB
VG UUID IglQep-hydn-lm2D-Dc1N-LsL4-edpi-BzgMuE

[root@lnx-svr-01 ~]#

We can see that it does, see the line:

Free PE / Size 1278 / 4.99 GiB

15. So we now need to allocate this extra 5GB (4.99GB to be precise), to Logical Volume video. Let’s first remind ourselves of how the Logical Volumes look right now:

[root@lnx-svr-01 ~]# lvs
  LV       VG       Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lv_root  VolGroup -wi-ao---- 17.51g
  lv_swap  VolGroup -wi-ao----  2.00g
  music    data     -wi-ao---- 10.00g
  pictures data     -wi-ao----  4.98g
  video    data     -wi-ao----  5.00g
[root@lnx-svr-01 ~]#

Logical Volume data has a capacity of 5GB.

16. Run lvextend per the below to allocate the free 5GB from Volume Group data to Logical Volume video:

[root@lnx-svr-01 ~]# lvextend -l +100%FREE /dev/data/video
Size of logical volume data/video changed from 5.00 GiB (1280 extents) to 9.99 GiB (2558 extents).
Logical volume video successfully resized

[root@lnx-svr-01 ~]#

The lvextend -l +100%FREE command allocates all free space to your chosen Logical Volume. To see more lvextend command options see this link.

17. Now resize the filesystem with resize2fs:

[root@lnx-svr-01 ~]# resize2fs /dev/data/video
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/data/video is mounted on /var/video; on-line resizing required
old desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/data/video to 2619392 (4k) blocks.
The filesystem on /dev/data/video is now 2619392 blocks long.
[root@lnx-svr-01 ~]#

18. Run lvs to confirm that Logical Volume video now has the extra 5GB of storage capacity:

[root@lnx-svr-01 ~]# lvs
  LV       VG       Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lv_root  VolGroup -wi-ao---- 17.51g
  lv_swap  VolGroup -wi-ao----  2.00g
  music    data     -wi-ao---- 10.00g
  pictures data     -wi-ao----  4.98g
  video    data     -wi-ao----  9.99g
[root@lnx-svr-01 ~]#

As you can see from the output above, the capacity of Logical Volume video has increased to 9.99GB – the increase was successful. Running df -h confirms the new size and shows that there is 4.9GB of free space available in filesystem /var/video:

[root@lnx-svr-01 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root
                       18G  908M   16G   6% /
tmpfs                 939M     0  939M   0% /dev/shm
/dev/sda1             477M   25M  427M   6% /boot
/dev/mapper/data-music
                      9.8G  4.4G  4.9G  48% /var/music
/dev/mapper/data-video
                      9.8G  4.4G  4.9G  47% /var/video
/dev/mapper/data-pictures
                      4.8G   10M  4.6G   1% /var/pictures
[root@lnx-svr-01 ~]#

The Happy Ending

I hope this post benefits anyone wanting to know how the filesystem expansion process on LVM works. LVM is very flexible and the ability to expand filesystems on-the-fly is priceless in a production environment. Good luck expanding!

Extend System Partition on a Windows Server 2003 VM using Dell ExtPart

There is no native tool that enables extending system partitions (C:\ drives) on Server 2003. There are multiple ways to perform this task, however, the only method that can be done online utilises a Dell utility called ExtPart. It can perform the extension of the system partition with no downtime although sometimes booting into Safe Mode and then running ExtPart is necessary to clear locks on the disk.

Note: This applies to Server 2003 only, newer versions of Windows do not suffer from this limitation, Disk Management as well as the diskpart are able to extend system partitions on-the-fly.

The first step is to download the ExtPart utility from this link. Click on the Download File link and save it to your desktop. The file is a self-extracting zip file called ExtPart.exe per the below:

20140201130639

Double-click on it and accept the default path it will extract the utility to:

20140201130715

Click on Unzip and the files will be extracted successfully:

20140201130747

To demonstrate how useful ExtPart is we will use an example whereby our demo VM has a 15 GB C:\ drive and it needs to be increased to 30 GB. A screenshot of the the current state of the C:\ drive is below:

20140201125606

We go into the VM settings and can see that the virtual disk is indeed 15 GB in size:

20140201125846

We increase the virtual disk size to 30 GB and apply the change:

20140201130043

Within the VM load Disk Management and select Action > Rescan Disks so that the system sees the newly added 15 GB of storage:

20140201130150

After the re-scan completes you will now see the extra 15 GB of unallocated space:

20140201130240

Now we need to run the ExtPart utility expand the C:\ drive so that it utilizes the 15 GB of unallocated space. To proceed, open the command prompt and go to the location where you extracted the ExtPart utility, in my case, C:\dell\ExtPart:

C:\>cd C:\dell\ExtPart

Then run ExtPart.exe:

C:\dell\ExtPart>extpart.exe

Enter the volume that is being expanded, in this example it is the C:\ drive so enter just C: without the backslash:

Volume to extend (drive letter or mount point): C:

Then enter the amount in MB to increase the volume by, I entered 15343:

Size to expand the volume (MB): 15343

The output will confirm the new size of the volume (C:\ drive), which is 30678 MB:

New volume size          :30678 MB (32169069568 bytes)

The full sequence of commands can be seen in the screenshot below:

20140201131412

When going back into Disk Management and re-scanning the disks, we can see that there is still 31 MB that is unallocated:

20140201131316

To add that remaining 31 MB to the C:\ drive, we go back to ExtPart and perform the same series of steps but this time add 31 MB:

Size to expand the volume (MB): 31

A screenshot of those steps is below:

20140201131707

Now going back into Disk Management you can see that the C:\ drive is using all of the provisioned space in the disk:

20140201131606

If the utility returns an error such as “the disk is not accessible” or “unable to connect to C:” then reboot the VM into Safe Mode and then run the same ExtPart commands. This is caused by various services locking the disk and preventing ExtPart from extending the volume. Booting into Safe Mode starts up the OS in a clean state, so only minimal services and drivers will run, thereby allowing ExtPart to expand the volume without interruption.