16

We're evaluting KVM for Linux virtualization on a few projects. All is going well so far. But one of our requirements is the ability to add disk space to a running guest without rebooting or taking it offline. Is this possible with KVM?

The only thing I've found so far (but have not tested yet) is the ability to hotplug disks into the machine. If I go this route, then I could always add the new disk to an LVM volume group on the guest and then extend the chosen logical volume. The biggest downside to this approach is that over time we might end up with guests having variable numbers of virtual disks. The "real" disk space would be provided to the host over a SAN, so we can always add more space to the host whenever.

1
  • (And "Yes", it's possible.)
    – poige
    Jan 18, 2019 at 12:53

5 Answers 5

5

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.

3
  • On further consideration, mounting the SAN storage from within the guest itself as you mention is probably the way to go. And thanks for the additional info as well.
    – Eil
    Mar 14, 2010 at 15:52
  • thin provisioning can be costly because of fragmentation, too.
    – wazoox
    Apr 23, 2010 at 20:20
  • 1
    The link is dead :(
    – MadMike
    May 28, 2021 at 9:20
21

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.

  1. 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

  1. 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.

2
  • 2
    Thanks for coming back and adding this answer! Makes things much simpler than the old way of doing it. Jul 14, 2017 at 9:38
  • 1
    In the example test is refering to the name of the VM. You can get info regarding the exitsing disk using virsh qemu-monitor-command example.com --hmp info block -v and help using virsh qemu-monitor-command example.com --hmp help. The --hmp parameter means human-readable and you need it as by default the command assumes you're providing JSON.
    – DustWolf
    Jan 5 at 12:37
4

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.

1
  • 2
    The problem isn't actually KVM-related; from Linux you simply cannot resize the disk you've booted from. It applies to physical RAID arrays, too.
    – wazoox
    Mar 12, 2010 at 23:03
3

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.

0

Not possible atm, but afaik it's a feature under development. What you can do instead is to connect to an iSCSI target from the VM and manage the space on that target on the SAN side.

5
  • You didn't answer the question with an answer he can use.
    – Mei
    Jan 5, 2012 at 17:17
  • @David: and what makes you think that and even downvote my answer? How does my answer not provide a workaround to the issue at hand?
    – dyasny
    Jan 5, 2012 at 17:21
  • You stated "Not possible atm..." then told him of a feature that isn't possible at the moment. (Now, almost two years later, it might be different - but this answer doesn't say that.)
    – Mei
    Jan 5, 2012 at 17:23
  • 1
    So two years ago I should have told him "it will be possible in two years"? Do I look like a prophet to you? Back then, hotplugging was under development, and that's exactly what I said. Then I offered a different approach to getting storage attached to the VM, that would be independent of the entire qemu featureset. Never stated it was the only approach, but it is a way.
    – dyasny
    Jan 5, 2012 at 17:28
  • I understand now... I edited your answer to better show your intent.
    – Mei
    Jan 5, 2012 at 17:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .