Qemu Vm Disk Resize Guide

Before You Start — Back Up Your VM

Always make a copy of your disk image before resizing. If anything goes wrong (wrong start sector, accidental signature removal, power loss mid-resize), your only recovery option is a backup.

# Shut down the VM first (can also be done via virt-manager GUI too)
virsh shutdown <vm-name>

# Copy the image (use -S for sparse file efficiency)
rsync -ahS --progress /var/lib/libvirt/images/your-disk.qcow2 /path/to/backup/

# Or simple copy
cp --sparse=always /var/lib/libvirt/images/your-disk.qcow2 /path/to/backup/

# Verify the backup
qemu-img check /path/to/backup/your-disk.qcow2

Note on copy speed: If your backup destination is on USB, make sure it’s connected via USB 3.0 (blue port). USB 2.0 will cap at ~25-35 MB/s and large images can take hours.


Step 1: Resize the Disk Image (Host Side)

With the VM shut down, expand the virtual disk:

# Add 100G to the image (adjust as needed)
qemu-img resize /var/lib/libvirt/images/your-disk.qcow2 +100G

# Verify the new size
qemu-img info /var/lib/libvirt/images/your-disk.qcow2

Caveats

  • Never resize while the VM is running — this can corrupt the image.
  • Commit or delete snapshots first — resizing images with internal snapshots can cause issues.
  • Shrinking is dangerous — if you shrink an image without first shrinking the guest filesystem, you will lose data.

Step 2: Boot the VM and Check the Layout

lsblk

Example output after resizing from 100G to 225G:

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
vda    254:0    0  225G  0 disk
├─vda1 254:1    0   99G  0 part /
├─vda2 254:2    0    1K  0 part          ← extended partition (container)
└─vda5 254:5    0  975M  0 part [SWAP]   ← swap inside extended partition

The disk is 225G but vda1 is still 99G. The swap partition (vda5) inside the extended partition (vda2) is blocking vda1 from being grown. We need to delete swap, grow vda1, and recreate swap at the end.


Step 3: Disable Swap

sudo swapoff /dev/vda5

Step 4: Repartition with fdisk

sudo fdisk /dev/vda

4a. Print and note the start sector of vda1

Command (m for help): p

Write down the start sector of vda1 (e.g., 2048). This is critical — you must use the exact same start sector when recreating the partition.

4b. Delete all partitions

Command (m for help): d
Partition number: 5

Command (m for help): d
Partition number: 2

Command (m for help): d
(deletes vda1, the only remaining partition)

This is safe. Deleting a partition only removes the partition table entry. The actual data on disk is untouched.

4c. Recreate vda1 with the same start sector

Command (m for help): n
Select: p
Partition number: 1
First sector: 2048              ← MUST match the original start sector
Last sector: -3G                ← leaves 3G at the end for swap (adjust as needed)

⚠️ CRITICAL: When asked “Do you want to remove the signature?” — answer N (No). Removing the signature destroys your filesystem.

4d. Create a new swap partition

Command (m for help): n
Select: p
Partition number: 2
First sector: (press Enter for default)
Last sector: (press Enter for default)

4e. Set the swap type

Command (m for help): t
Partition number: 2
Hex code: 82

4f. Set the boot flag on partition 1

Command (m for help): a
Partition number: 1

4g. Verify and write

Command (m for help): p

Check that:

  • vda1 starts at the correct sector (e.g., 2048) and has the expected size
  • vda2 is at the end with your desired swap size
  • vda1 has the boot flag (*)
Command (m for help): w

Step 5: Resize the Filesystem

sudo resize2fs /dev/vda1

Step 6: Recreate and Enable Swap

sudo mkswap /dev/vda2
sudo swapon /dev/vda2

Step 7: Update /etc/fstab

The new swap partition has a new UUID. If you don’t update fstab, the system will hang on boot waiting for the old swap UUID (90-second timeout).

# Get the new swap UUID
sudo blkid /dev/vda2

# Edit fstab
sudo nano /etc/fstab

Replace the old swap UUID with the new one on the swap line.


Step 8: Verify

df -h /
lsblk
free -h

You should see the expanded filesystem, the new partition layout, and active swap.


Quick Reference — Common Pitfalls

Mistake Consequence
Resizing the image while the VM is running Possible image corruption
Using the wrong start sector when recreating vda1 Filesystem will not mount (data loss)
Saying “Yes” to removing the ext4 signature Filesystem is destroyed
Forgetting to update /etc/fstab with the new swap UUID 90-second hang on every boot
Shrinking an image without shrinking the filesystem first Data loss / corruption
Not backing up before resizing No recovery if something goes wrong