Is online disk resize possible with KVM?

Solution 1:

I know that's an old question but I've found it while googling for the solution and hope it may help someone else.

As for today it is possible to resize the hard drive on the machine. I've found a working way here:

https://bugzilla.redhat.com/show_bug.cgi?id=648594

The following steps must be performed:

1. Find out a file name and KVM device name of the hard drive you want to resize:

   root@vhstage02:/data# virsh dumpxml test | xpath -e /domain/devices/disk
   Found 2 nodes in stdin:
   -- NODE --
   <disk type="file" device="disk">
     <driver name="qemu" type="qcow2" />
     <source file="/data/test.img" />
     <backingStore />
     <target dev="vda" bus="virtio" />
     <alias name="virtio-disk0" />
     <address type="pci" domain="0x0000" bus="0x00" slot="0x04" function="0x0" />
   </disk>
   -- NODE --
   <disk type="file" device="cdrom">
     <driver name="qemu" type="raw" />
     <source file="/data/images/debian-8.2.0-amd64-netinst.iso" />
     <backingStore />
     <target dev="hda" bus="ide" />
     <readonly />
     <alias name="ide0-1-1" />
     <address type="drive" controller="0" bus="1" target="0" unit="1" />
   </disk>
   

The one interesting for us is disk. You should look for source and alias blocks. For me file name is test.img and alias name is virtio-disk0. To this name, you need to prepend drive- to get qemu drive name.

2. Now we actually resize the drive using qemu monitor:

   virsh qemu-monitor-command test block_resize  drive-virtio-disk0  100G --hmp
   

Note that filename was used without .img extension and drive- was added to disk alias. The 100G is the resulting size of the drive we want to have

3. Login to the machine and check that actual size was changed:

   root@test:~# fdisk -l
   
   Disk /dev/vda: 100 GiB, 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
   Disklabel type: dos
   Disk identifier: 0x7e6e7f71
   
   Device     Boot  Start       End   Sectors  Size Id Type
   /dev/vda1  *      2048    499711    497664  243M 83 Linux
   /dev/vda2       501758 167770111 167268354 79.8G  5 Extended
   /dev/vda5       501760 167770111 167268352 79.8G 8e Linux LVM
   

That's it! Now you can either create new partitions or resize existing ones.

Solution 2:

AFAIK, this is not possible -- you can add new disk images, and as you point out you could also add new images to an LVM volume, but in order to resize an active, bootable disk image you need to be able to shut it down and edit the partitions.

Here's a good explanation for expanding an image. Although it requires shutdown, you could probably get away with only a couple of minutes of downtime, especially if you avoid the --nonsparse image option and dd the gparted disk to an iso file and mount in your KVM guest in advance. Hope this helps.

---

Solution 3:

I think you're stuck doing what you've mentioned if you want to do it without taking the machine down.

Why not just give the virtual machines LUNs right off the SAN and manage the space there? This works better if you want to use features like live migration anyhow.

KVM is based on QEMU so all it's image format support comes from that project. Here's a good how-to resize the various formats that Qemu/KVM support. But the Qemu forum would be a good place to ask this question if you don't get any solid answers here.

Another option which may not be ideal is to use really large qcow2 or other sparse image format for the drives. So you could give each machine a small drive for the OS and a large sparse image for data under LVM. This would at least keep the number of virtual drives/images that you're having to manage. But this thin provisioning could be a problem though if you do this to 1000 machines and everyone takes you up on the free space that they see.

XEN I believe has the same limitations currently.

---

Solution 4:

It is possible to move a Linux system between disks while it's running. The limitation is that you cannot alter partitions on a disk that has partitions in use.

To do this your root filesystem must be on an LVM, this often means that you have to have a separate boot filesystem (this is not, however, essential, it just makes things easier)

After plugging in the new disk, you add it to the LVM with vgextend, use pvmove to move the rootfs to the new disk, use lvextend and resize2fs to expand the logical volume and filesystem respectively then use vgreduce to remove the old disk from the volume group. Once removed the old volume can be unplugged.

For the simple case you have a tiny disk for the boot filesystem that you never have to touch. But if it's on it's own it's easy to unmount it unplug it, plug in a new one and rebuild the boot disk without stopping the system. (just don't crash while you're doing it)

Note: resize2fs can also shrink filesystems.