2

The KVM host server is running CentOS 6.5 and a LVM volume group "storage_pool" is used as the main storage pool for KVM.

An Ubuntu guest is installed using an ext4 filesystem and mounts the whole /dev/vda1 as /. This is the guest disk configuration:

<disk type='block' device='disk'>
  <driver name='qemu' type='raw' cache='none' io='native'/>
  <source dev='/dev/storage_pool/kvmguest.img'/>
  <target dev='vda' bus='virtio'/>
  <alias name='virtio-disk0'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>

What would be the best approach to increase the guest disk size? The VG has a lot of free space.

I have found some examples but most use LVM inside the guests as well, or weren't completely applicable. As far as I understand, the common method is to create a larger LV in the same VG, shutdown the guest, transfer the data, edit the configuration to use the new LV?

Thanks in advance for any suggestions or pointers

f10bit
  • 131
  • 1
  • 1
  • 6

5 Answers5

7

There is no need to shutdown the guest (at least no longer in 2019).

Simply

lvextend -L+<size>G /dev/<group>/<volume>

then

virsh blockresize <domain> /dev/<group>/<volume> --size <newsize>

and finally go into your guest and do whatever is necessary in your guest to make use of the extra space.

In a Windows guest you can do

diskpart

list volume

select volume <n>

extend

These are the exact steps I followed to expand the C: drive of a Windows 10 guest running as KVM domain under Ubuntu 19.04 with qemu 3.1.0

Colin 't Hart
  • 283
  • 2
  • 16
  • Does blockresize allow --size option name before the size? Manual documents positional arguments only: blockresize domain path size – John Mahowald Oct 03 '21 at 02:29
1

This is the procedure I went with:

  1. Extend the logical volume of the kvm guest

    # lvextend -L+50G /dev/storage_pool/guest.img

  2. Shutdown the kvm guest and deactivate the logical volume

    # virsh shutdown guest
# lvchange -a n /dev/storage_pool/guest.img

  3. List and note the partition information of the kvm guest, most importantly the first sector. If it doesn't display sectors you may need to add the '-u' or '-u sectors' switch

    # fdisk -l /dev/storage_pool/guest.img

  4. Delete and recreate the partition to fill the whole extended space, make sure you are using sectors as units and to select the same first sector (usually 2048 if partition is aligned), you can use the 'u' fdisk command to toggle between units

    # fdisk /dev/storage_pool/guest.img
Command (m for help): d
Partition number (1-4): 1
Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First sector (...): 2048
Last sector...: hit enter and use the default last sector
Command (m for help): a
Partition number (1-4): 1
Command (m for help): w

  5. Expose the ext3/4 filesystem and resize it

    # kpartx -a -v /dev/storage_pool/guest.img
# e2fsck -p -f /dev/mapper/storage_pool-guest.img1
# resize2fs /dev/mapper/storage_pool-guest.img1
# e2fsck -p -f /dev/mapper/storage_pool-guest.img1
# kpartx -d -v /dev/storage_pool/guest.img

  6. Activate the logical volume and start the kvm guest

    # lvchange -a y /dev/storage_pool/guest.img
# virsh start guest
f10bit
  • 131
  • 1
  • 1
  • 6
0

Searching for the same thing, I found your question with no answers yet. For me, the following thing has worked:

  1. shut down the guest (in my case, a debian 7.0) in the usual way.

  2. extend the "original" LV (in the host's VG, of course), e.g., by 5G. For this, you have to be root/sudo on the host:

    lvextend -L +5G /dev/YourStoragePoolVG/YourVirtualMachinesVGToExtend

  3. Open the newly extended lv (i.e., the "disk" of your VM) in gparted:

    gparted /dev/mapper/YourStoragePoolVG-YourVirtualMachinesVGToExtend

  • Note: You must use the "/dev/mapper/..." path, not "/dev/dm-77" or "/dev/YourStoragePoolVG/..." or other (this seems to be a bug/feature of LVM)!
  1. Fiddle around the partitions on the modified volume (use the GUI as usually)
  • Note: Consider the warnings about data loss, fs types etc.!
  • Note: Be careful.
  • In gparted, you can resize partitions and move them around in the partition table stored on the virtio disk within the LV.
  • Extending one or more partitions is IMHO not a problem. For partition/fs shrinking, use Google...
  • gparted also adapts the filesystems on the partitions (not only the partitions themselves.
  1. Restart your VM. It now sees the modified partitions.

As I said, this worked for me (I could try this on some toy installation without taking risks). Could somebody please review the above instruction and comment if this works in general? Thankyou.

HelpingHand
  • 9
  • 1
0

Anyone who looking for an answer for this question, need to check out this:

KVM guest doesn't recognize new size of raw disk after lvresize

I think virsh blockreisze is much better than fdisk or parted.

Community
  • 1
pingz
  • 213
  • 1
  • 6
  • Please don't post url-only answers. The linked website can disappear anytime and the answer would be useless. Always copy important parts into the answer itself. – Marki555 Jan 31 '20 at 20:35
  • @Marki555 another people already covered that. check this: https://serverfault.com/a/968764/119191 two years later, – pingz Feb 02 '20 at 10:36
0

It's easy - after host's LVEXTEND|LVRESIZE boot into the VM from a LiveCD ISO having GPARTED on board. Once the CD boot completes, run GPARTED with root partition name used WITHIN the VM: 

$ gparted /dev/vda1" # for VirtIO /dev/vda

or

$ gparted /dev/sda1" # for SATA emulated /dev/sda

and perform partition resizing the usual way of GPARTED

RalfFriedl
  • 3,008
  • 4
  • 12
  • 17
Mad Calm
  • 1