KVM Online Disk Expansion: How to Extend Virtual Disks Without Downtime

|
Published:
|
|
KVM Online Disk Expansion: How to Extend Virtual Disks Without Downtime

In this guide, I will walk you through KVM online disk expansion: how to extend virtual disks without downtime. But is it really possible to expand KVM virtual machine drive while the vm is running? Of course, yes! In today’s fast-paced IT environments, virtual machine storage requirements can change rapidly. When critical workloads need additional disk space, the traditional approach of shutting down VMs for disk resizing causes unacceptable downtime. Fortunately, Kernel-based Virtual Machine (KVM) supports online disk expansion, allowing system administrators to extend virtual disks while VMs continue running. Let’s check out!

KVM Online Disk Expansion: How to Extend Virtual Disks Without Downtime

Why Online Disk Expansion Matters

Performing online disk resizing offers several significant advantages:

  • Zero downtime: Critical services remain available during the entire process.
  • Improved operational flexibility: Respond to changing storage needs in real-time.
  • Enhanced resource utilization: Allocate storage resources more efficiently.
  • Better user experience: End users experience no service interruptions

Prerequisites

Before you begin, ensure:

  • You have root or sudo access to the hypervisor host as well the virtual machine whose disk drive is being expanded..
  • You’re working with KVM-managed virtual machines (typically using libvirt).
  • The disk format supports dynamic resizing (e.g., QCOW2 or raw).
  • You have additional disk space available on the host enough to support VM disk drive requirements.
  • ⚠️ Very Important! Always back up any critical data before working on the drives.

Understanding KVM Storage Formats

KVM virtual machines typically use disk image formats such as:

  • QCOW2: QEMU Copy-On-Write format, offering features like snapshots and compression.
  • RAW: Simple disk image format with better performance but fewer features.

Other supported but less commonly used disk formats include:

  • VMDK: VMware’s Virtual Machine Disk format, useful for migrating from VMware environments.
  • VDI: VirtualBox Disk Image format, enabling compatibility with VirtualBox VMs.
  • VHD/VHDX: Microsoft’s Virtual Hard Disk formats, used in Hyper-V environments.

Step-by-Step: How to Extend KVM VM Disk Without Downtime

Follow these steps to safely extend a virtual disk on a running KVM VM:

1. Identify the Running VM

First, list all running virtual machines on the KVM host to identify the target VM:

sudo virsh list

This command will display output similar to:

 Id   Name               State
----------------------------------
 1    dns                running
 2    gw                 running
 3    lb                 running
 4    node-mw-01         running
 5    node-mx-02         running
 6    node-my-03         running
 7    node-01            running
 8    node-02        	 running
 9    node-03        	 running
 13   u24                running

Note the name of the VM you need to resize (referred to as “domain” in KVM terminology).

2. Identify the Target Disk Device

Next, determine which virtual disk needs to be resized using the command below:

sudo virsh domblklist <domain>

For example, let’s say the, from the list above, we are dealing with the VM with u24 as domain name. Hence, to get the virtual drives on the vm;

sudo virsh domblklist u24

This will show output similar to:

 Target   Source
---------------------------------------------------
 vda      /var/lib/libvirt/images/u24-noble.qcow2
 vdb      /var/lib/libvirt/images/u24.qcow2

I have two drives on the virtual machine. I literally need to resize the second drive (target: vdb) that is storing some of my data on the VM.

The Target column shows the device name as seen by the VM (e.g., “vda” or “vdb”), while the Source column shows the actual path to the disk image file on the host system.

Therefore, take note of the Target name (like vda or vdb) or the full path to the disk.

3. Resize the Virtual Disk Online

Now, it is time to extend the virtual machine drive.

However, before you can proceed, it is paramount to have an idea of the current size of the respective VM drive on the host.

Note
The qemu-img tool cannot be used directly with running virtual machines (VMs) because it operates on disk image files at the block level, and modifying or accessing these files while a VM is running can lead to data corruption or inconsistent states. Luckily, the QEMU process enforces a write lock on the disk image of a running VM to prevent accidental corruption. Attempting to use qemu-img on a running VM’s disk image typically results in an error like: qemu-img: Could not open 'image.qcow2': Failed to get shared "write" lock

Since we cannot use qemu-img directly on a running VM, then an alternative command to get the disk information is virsh domblkinfo. The syntax of this command is:

domblkinfo <domain> [--device <string>] [--human] [--all]

For example, in step two above, I listed the drives on a virtual machine (sudo virsh domblklist) to get the specific drive that I needed to work on. In my case, for my virtual machine, u24, the drive that I need to work on is vdb.

Therefore, to get the size info of drive vdb for the u24 domain;

sudo virsh domblkinfo u24 vdb --human

The command will show an output similar to:

Capacity:       10.000 GiB
Allocation:     11.504 MiB
Physical:       4.501 GiB

Where:

  • Capacity: is the total virtual size of the disk as seen by the guest VM (i.e., 10 GiB).
  • Allocation: is the amount of space allocated within the virtual image file (often just metadata).
  • Physical: is the actual disk space used on the host by the image (e.g., in /var/lib/libvirt/images).

Therefore, my current disk size as seen by VM is 10G.

You can even login to the VM via SSH or console and run lsblk command to list the drives;

lsblk

Sample command output;

NAME                      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
vda                       253:0    0   25G  0 disk
├─vda1                    253:1    0    1M  0 part
├─vda2                    253:2    0    2G  0 part /boot
└─vda3                    253:3    0   23G  0 part
  └─ubuntu--vg-ubuntu--lv 252:0    0   23G  0 lvm  /
vdb                       253:16   0   10G  0 disk
├─vdb1                    253:17   0    1G  0 part /mnt/1
├─vdb2                    253:18   0    2G  0 part /mnt/2
└─vdb3                    253:19   0    7G  0 part /mnt/3

Drive vdb refers. I will be extending this drive to 20GB. i.e, I will add 10GB more.

Now, that we have the current disk size, let’s proceed to resize the drive. But now since we have mentioned that we cannot use qemu-img to extend the disk size, an alternative command to expand KVM VM disk’s online is virsh blockresize.

From the help page;

sudo virsh blockresize --help
  NAME
    blockresize - Resize block device of domain.

  SYNOPSIS
    blockresize <domain> <path> <size>

  DESCRIPTION
    Resize block device of domain.

  OPTIONS
    [--domain] <string>  domain name, id or uuid
    [--path] <string>  Fully-qualified path of block device
    [--size] <number>  New size of the block device, as scaled integer (default KiB)
☠️ Important:
The size value can use units like G (gigabytes), M (megabytes), etc. Always specify larger sizes than the current disk size, as online shrinking is not supported and could lead to data loss. Also note that the size doesn’t refer to the additional drive size but the total resulting size after adding the extra space.

For example, to resize the vdb disk of u24 VM to 20GB (from 10G, added 10G):

sudo virsh blockresize u24 /var/lib/libvirt/images/u24.qcow2 20G

Alternatively, you can use the drive target instead of the path.

sudo virsh blockresize u24 vdb 20G

This command will give an output similar to:

Block device '/var/lib/libvirt/images/u24.qcow2' is resized

Or the target drive is you used that alternative method.

4. Verify the Resize Operation

To confirm the disk has been resized at the hypervisor level:

sudo virsh domblkinfo u24 vdb --human
Capacity:       20.000 GiB
Allocation:     11.504 MiB
Physical:       4.501 GiB

It is now expanded, on the host level!

5. Final Step: Expand the Filesystem Inside the VM

While the disk device has been extended at the hypervisor level, the guest OS is not automatically aware of this change. You need to update the partition table and file system inside the VM.

For Linux VMs (for example Ubuntu 24.04 in case):

Connect to the VM using SSH or console access.

Confirm disk drive expansion:

lsblk

Sample command output, see that vdb is now at 20G but the filesystem still remains same:

NAME                      MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
vda                       253:0    0  25G  0 disk 
├─vda1                    253:1    0   1M  0 part 
├─vda2                    253:2    0   2G  0 part /boot
└─vda3                    253:3    0  23G  0 part 
  └─ubuntu--vg-ubuntu--lv 252:0    0  23G  0 lvm  /
vdb                       253:16   0  20G  0 disk 
├─vdb1                    253:17   0   1G  0 part /mnt/1
├─vdb2                    253:18   0   2G  0 part /mnt/2
└─vdb3                    253:19   0   7G  0 part /mnt/3

Now, depending on whether the drive is configured with LVM or not and the type of filesystem, different steps can be taken to extend the drive filesystem.

As you can see from the lsblk command output above, drive vda is LVM partitioned while the other one that we just extended is non-LVM.

Extending Non-LVM Partitions:

So, to extend the partition of non-LVM drives, you can use growpart command to extend the specific partition on the drive. Note that growpart expands the partition to the maximum available space on the device and does not support specifying the size.

For example, considering that my vdb drive has three partitions, let’s say I need to extend partition 3, then I can just expand using the command below;

sudo growpart /dev/vdb 3

Sample command output;

CHANGED: partition=3 start=6293504 old: size=14678016 end=20971519 new: size=35649503 end=41943006

The drive (partition 3, /dev/vdb3 in the above example) should now be extended;

lsblk
NAME                      MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
vda                       253:0    0  25G  0 disk 
├─vda1                    253:1    0   1M  0 part 
├─vda2                    253:2    0   2G  0 part /boot
└─vda3                    253:3    0  23G  0 part 
  └─ubuntu--vg-ubuntu--lv 252:0    0  23G  0 lvm  /
vdb                       253:16   0  20G  0 disk 
├─vdb1                    253:17   0   1G  0 part /mnt/1
├─vdb2                    253:18   0   2G  0 part /mnt/2
└─vdb3                    253:19   0  17G  0 part /mnt/3

What if you want to share the same additional storage space across multiple partitions on the same drive? For example, you added 10GB additional space to the a drive, say vdb and you want to add 3GB to /dev/vdb2 and 7GB to /dev/vdb3. For LVM partitioned drives, that can easily be handled by adding the required size of the space from the volume group to the respective logical volume. However, for non-LVM drives, additional space cannot be freely shared among contiguous partitions, because changing a partition’s start sector causes data loss — making resizing practically impossible without deleting or moving adjacent partitions. Therefore, extend the drive from the hypervisor level to add a respective space for every partition you need to extend.

Once the partition is extended, extend the underlying filesystem as well.

You can find out your partition FS using option -T to the df command (Type column).

df -hT

Example output;

Filesystem                        Type   Size  Used Avail Use% Mounted on
tmpfs                             tmpfs  392M  1.2M  391M   1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv ext4    25G  6.4G   18G  28% /
tmpfs                             tmpfs  2.0G  1.2M  2.0G   1% /dev/shm
tmpfs                             tmpfs  5.0M     0  5.0M   0% /run/lock
/dev/vdb3                         xfs    7.0G  169M  6.8G   3% /mnt/3
/dev/vdb1                         xfs    960M   52M  909M   6% /mnt/1
/dev/vdb2                         xfs    2.0G   71M  1.9G   4% /mnt/2
/dev/vda2                         ext4   2.0G  185M  1.7G  11% /boot

So, if you are dealing with an XFS filesystem, extend the filesystem using xfs_grow command. Replace partition number accordingly.

sudo xfs_growfs /dev/vdb3

For an EXT4 FS, use resize2fs command;

sudo resize2fs /dev/vdb3

Extending LVM Partitions:

For LVM partitions, list the physical volumes drive;

sudo pvs

For example, this is the sample output;

  PV         VG        Fmt  Attr PSize   PFree
  /dev/vda  ubuntu-vg lvm2 a--  <23.00g    0

The physcial volume partition is /dev/vda. Then, extend the Physical volume to the additional space:

sudo pvresize /dev/vda

Sample command output;

  Physical volume "/dev/vda" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized

If the Physical volume is on a partition, say /dev/vda3, then you need to extend the partition first;

sudo growpart /dev/vda3

Then extend the Physical volume:

sudo pvresize /dev/vda3

Once you have the extended the PV, then the VG should now be having some space over which you can expand your logical volumes to.

For example, say you have two logical volumes (lv-01 and lv-02) on same volume group (vol-01), you can share the available space between the two.

If you want to, say, add 5G (option -L) to lv-01 and resize the underlying filesystem automatically (option -r), then:

sudo lvextend -r -L +5G /dev/VG/LV

E.g

sudo lvextend -r -L +5G /dev/ubuntu-vg/ubuntu-lv

That is all.

Confirm using the df command:

df -hT

For Windows VMs:

  1. Open Disk Management (diskmgmt.msc).
  2. Right-click on the partition and select "Extend Volume".
  3. Follow the wizard to allocate the newly available space.

Best Practices for Online Disk Expansion

For optimal results when performing online disk expansion:

  • Create snapshots before resizing: Always back up your VM or create a snapshot before making changes
  • Use LVM inside VMs: LVM provides more flexibility for storage management
  • Monitor performance during resizing: Large disk expansions can impact I/O performance
  • Document all changes: Keep records of all storage modifications for troubleshooting
  • Test the process in non-production: Validate your approach before applying to critical systems

Alternatives to Online Disk Expansion

While online disk expansion is convenient, alternative approaches include:

  • Adding new virtual disks: Sometimes adding a separate disk is cleaner than resizing
  • Implementing storage tiering: Move less-accessed data to secondary storage
  • Using network storage: NFS or SAN storage can offer more flexibility
  • Scheduled maintenance windows: For non-critical systems, planned downtime may be acceptable
  • Ensuring proper log rotation: Implementing effective log rotation policies can prevent logs from consuming excessive disk space, reducing the frequency of disk expansion needs
  • Data archiving and cleanup: Regularly identify and remove temporary files, old logs, and unnecessary data to free up existing disk space
  • Monitoring and alerting: Implement proactive monitoring to identify storage trends and address space issues before they become critical

Conclusion

Online disk expansion in KVM environments provides a powerful way to respond to changing storage needs without service interruption. By following the steps outlined in this guide, system administrators can confidently manage virtual disk space while maintaining system availability. Remember that proper planning and testing are essential before performing these operations in production environments.

Additional Resources

SUPPORT US VIA A VIRTUAL CUP OF COFFEE

We're passionate about sharing our knowledge and experiences with you through our blog. If you appreciate our efforts, consider buying us a virtual coffee. Your support keeps us motivated and enables us to continually improve, ensuring that we can provide you with the best content possible. Thank you for being a coffee-fueled champion of our work!

Photo of author
Kifarunix
Linux Certified Engineer, with a passion for open-source technology and a strong understanding of Linux systems. With experience in system administration, troubleshooting, and automation, I am skilled in maintaining and optimizing Linux infrastructure.

Leave a Comment