Gnome Partition Editor

— ny_wk

GParted (the GNOME Partition Editor) is a free, open-source tool that lets you create, resize, move, copy, and repair disk partitions through a graphical interface, without destroying the data already on them. It is the go-to utility when you need to grow a full root or C: drive, carve out room for a second operating system, or rescue a partition table that has gone missing.

Because GParted writes directly to the partition table and to live filesystem metadata, the single most important rule is to run it against an unmounted partition. The safest way to do that is to boot a machine (or virtual machine) from GParted Live, the standalone bootable image, so the disk you want to edit is never in use while you edit it. This guide walks through the full workflow and the VMware angle that trips up so many admins: what to do when vCenter refuses to grow a disk because the controller is set to IDE.

What GParted can and cannot do

GParted is a front end for a stack of mature command-line partitioning and filesystem tools (such as parted, e2fsprogs, and ntfsprogs). It exposes their power through a clear visual map of every disk on the system, so you can see exactly how space is allocated before you change anything.

On partitions you can create, delete, resize, move, check for errors, relabel, assign a new UUID, and copy and paste an entire partition to another drive. It supports both MBR (msdos) and GPT partition tables.

It also understands a wide range of filesystems, either fully (resize plus move) or read-only, depending on the helper tools installed:

• btrfs
• ext2 / ext3 / ext4
• fat16 / fat32 / exfat
• hfs / hfs+
• linux-swap
• lvm2 pv (LVM physical volumes)
• nilfs2
• ntfs
• reiserfs / reiser4
• udf, ufs, xfs (note: xfs supports growing but not shrinking)

What GParted is not is a magic undo button. Moving the start of a partition rewrites a lot of metadata, and a power failure mid-operation can corrupt a filesystem. Always have a verified backup before you resize anything important.

System requirements for GParted Live

GParted Live runs on x86 and x86-64 computers and is hardware-agnostic about the host operating system: the same media boots and edits disks whether the box normally runs Linux, Windows, or macOS, because you boot the GParted environment instead of the installed OS. You need roughly 320 MB of RAM to load the full live image comfortably (the classic minimum often quoted was 128 MB, but modern builds want more), and a way to boot from removable media: a USB stick, a CD/DVD, or, on a virtual machine, an attached ISO.

How to boot GParted Live on a VMware VM

The most common professional use of GParted is inside a virtual machine, where you have just enlarged the virtual disk and now need the guest to actually use the new space. Here is the reliable, ordered procedure.

1. Download the current GParted Live ISO from the official project and place it on a datastore or your local workstation.
2. In vCenter, open the target VM's settings and attach the ISO to the virtual CD/DVD drive. Tick Connect at power on so the drive is live when the VM boots.
3. Make sure the VM's boot order favors the CD/DVD, or force the firmware/boot menu on the next restart.
4. Reboot the VM. It will start from the ISO and present the GParted Live boot menu.
5. Accept the default boot entry, then choose your keymap and language (the defaults are fine for most users), and let it start the X session. GParted opens automatically with a panel showing every detected disk.
6. In the top-right device selector, pick the disk you want to edit. The main window draws each partition to scale and lists its filesystem, size, used space, and flags.

Resize or move a partition step by step

Once GParted is open and you have selected the correct disk, the core resize workflow looks like this. The classic case is reclaiming newly added virtual disk space into an existing partition.

1. Select the partition you want to change and click Resize/Move (or right-click and choose it).
2. In the dialog, drag the partition's right edge to fill the free space, or type the exact value into New size (MiB). To grow into space that sits before the partition, you will need to move it, which takes longer.
3. Leave Align to set to MiB (the modern default that keeps SSDs and advanced-format drives properly aligned).
4. Click Resize/Move to queue the operation. Nothing has been written yet; GParted batches changes.
5. Review the pending operations list at the bottom of the window, then click the green Apply All Operations checkmark and confirm.
6. Wait for every operation to report Completed. Do not interrupt it. Close the details dialog when done.

To create a new partition instead, select the unallocated space, click New, choose primary or logical, set the size and filesystem (for example ext4), give it a label, and apply. To copy a partition, right-click it, choose Copy, select unallocated space on the destination disk, and choose Paste.

When vCenter will not expand the disk: the IDE controller problem

Sometimes the Edit Settings dialog in vCenter grays out or refuses the disk-size field. The usual cause is that the virtual disk is attached to an IDE controller rather than SCSI/PVSCSI. IDE virtual disks cannot be hot-extended and often cannot be extended through the GUI at all. In that situation, extend the VMDK from the ESXi command line with vmkfstools.

The -X (extend) flag grows the backing virtual disk to a new total size. Here is a corrected example that grows a disk to 20 GB:

1. Enable and open an SSH session to the ESXi host, then change into the datastore folder that holds the VMDK:
   cd /vmfs/volumes/G2-M610-1-SYMCLASS-SMOKETEST/10092011st110
2. Power off the VM first. A running VM holds a lock on its disk files. Run the extend command:
   vmkfstools -X 20G 10092011st110.vmdk
3. Power the VM back on (or proceed to mount the disk elsewhere).

Why the shutdown matters: if you try to extend the VMDK of a powered-on VM, the operation fails with a locking error like this:

Failed to extend disk : Failed to lock the file (16392).

Error 16392 means another process (the running VM) already holds the file lock. Shutting the VM down releases the lock and the extend succeeds. Note also that vmkfstools -X only grows the container; the guest's partition and filesystem are still the old size until you grow them too.

Growing the partition after extending the VMDK

After vmkfstools -X enlarges the virtual disk, the guest sees a bigger disk but the existing partition and filesystem do not change on their own. You have two good ways to consume the new space.

Option A: GParted Live (graphical, OS-agnostic). Boot the VM from the GParted ISO as described above, select the disk, drag the target partition's right edge into the new free space, and apply. GParted grows both the partition and the filesystem in one operation. For a Windows guest where the system partition is locked, the source workflow's tip still applies: detach the disk and attach it as a secondary disk to a helper VM, grow it there, then reattach. This sidesteps the limits of Windows diskpart on an active primary partition.

Option B: from inside the guest (command line). On a Linux guest you often do not even need GParted. Rescan the disk and grow the partition and filesystem live:

1. Tell the kernel to re-read the new disk size:
   echo 1 > /sys/class/block/sda/device/rescan
2. Grow the last partition to fill the disk (sda, partition 1 here):
   growpart /dev/sda 1
3. Grow the filesystem. For ext4:
   resize2fs /dev/sda1
   For xfs (must be mounted):
   xfs_growfs /
4. If the partition is an LVM physical volume, run pvresize /dev/sda1, then lvextend -r -l +100%FREE /dev/vg/lv.

Common pitfalls to avoid

• Editing a mounted partition. Never resize the partition that the running OS is booted from. Boot GParted Live or move the disk to a helper VM.
• No backup. A move operation rewrites large amounts of metadata; treat it as risky and snapshot the VM or back up files first.
• Forgetting the VM is on. The 16392 lock error and most hot-extend failures vanish once the VM is powered off.
• Stopping at the VMDK. Extending the disk is only step one; the partition and filesystem still need to grow.
• Trying to shrink xfs. xfs can only grow. Plan capacity accordingly.
• Wrong device name. Double-check with lsblk before running any destructive command so you do not operate on the wrong disk.

Verification: confirm the change worked

After resizing, verify before you declare success.

• In GParted itself, the partition map should now show the new size with no pending operations and no warning icons.
• On a booted Linux guest, run lsblk and df -h to confirm both the partition and the mounted filesystem report the larger capacity.
• On Windows, open Disk Management (or diskpart > list volume) and confirm the volume reflects the new size.
• Run a filesystem check on the resized partition (GParted's Check action, or fsck while unmounted) to confirm metadata integrity.
• Reboot the guest normally and confirm it boots and mounts everything cleanly.

Modern context

GParted remains actively maintained and is still the best graphical choice for offline partition surgery across operating systems. For day-to-day virtual disk growth on modern VMware, prefer SCSI/PVSCSI controllers, which support hot-extend, and use in-guest tools like growpart and resize2fs for zero-downtime expansion. Reach for GParted Live when a disk cannot be edited online, when you are dealing with a Windows system partition, or when you need to rescue a damaged partition table.

Key Takeaways

• GParted resizes, moves, copies, and repairs partitions without data loss, across Linux, Windows, and macOS disks.
• Always edit an unmounted partition: boot GParted Live or attach the disk to a helper VM.
• If vCenter will not grow a disk, the controller is likely IDE; extend with vmkfstools -X 20G disk.vmdk after powering the VM off.
• The lock error 16392 simply means the VM is still running, shut it down and retry.
• Extending the VMDK is only half the job, you must then grow the partition and filesystem with GParted, growpart/resize2fs, or LVM tools.

Frequently Asked Questions

Is GParted safe for resizing a partition without losing data?

Yes, when used correctly. GParted is designed for non-destructive resizing and moving, and it is widely trusted in production. The risks come from interrupting an operation (power loss) or editing a mounted partition. Boot from GParted Live, keep the VM powered, and have a backup, and resizing is routine.

Why is the disk size field grayed out when I try to expand a VM disk?

The virtual disk is almost always attached to an IDE controller, which cannot be extended through the vCenter GUI. Either migrate the disk to a SCSI/PVSCSI controller, or extend it from the ESXi shell with vmkfstools -X while the VM is powered off.

What does "Failed to lock the file (16392)" mean in vmkfstools?

It means another process, the powered-on virtual machine, already holds a lock on the VMDK. vmkfstools -X cannot extend a disk that is in use. Shut the VM down to release the lock, run the extend command, then power it back on.

After I grow the VMDK, why does the guest still show the old size?

Because vmkfstools -X only enlarges the virtual disk container. The partition table and filesystem inside the guest are unchanged until you grow them, either graphically in GParted Live or from inside the guest with growpart and resize2fs (Linux) or Disk Management (Windows).

For more hands-on Linux and system administration walkthroughs, subscribe on YouTube @explorenystream.