linux - Resizing LVM partition for KVM guest

19
2014-04
  • HTF

    I've created LVM partition for the KVM guest. The KVM guest is also using LVM partitions itself.

    The initial size of the guest's LVM partition was 160GB on the hypervisor. I've extended to 200GB.

    I've rebooted the guest and it recognized the new size:

        # fdisk -l
    
    Disk /dev/vda: **214.7 GB**, 214748364800 bytes
    16 heads, 63 sectors/track, 416101 cylinders
    Units = cylinders of 1008 * 512 = 516096 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0x000c1b11
    
       Device Boot      Start         End      Blocks   Id  System
    /dev/vda1   *           3        1018      512000   83  Linux
    Partition 1 does not end on cylinder boundary.
    /dev/vda2            1018      332882   167259136   8e  Linux LVM
    Partition 2 does not end on cylinder boundary.
    
    Disk /dev/mapper/vg_main-lv_root: 8589 MB, 8589934592 bytes
    255 heads, 63 sectors/track, 1044 cylinders
    Units = cylinders of 16065 * 512 = 8225280 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0x00000000
    
    Disk /dev/mapper/vg_main-lv_root doesn't contain a valid partition table
    
    Disk /dev/mapper/vg_main-lv_swap: 4294 MB, 4294967296 bytes
    255 heads, 63 sectors/track, 522 cylinders
    Units = cylinders of 16065 * 512 = 8225280 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0x00000000
    
    Disk /dev/mapper/vg_main-lv_swap doesn't contain a valid partition table
    
    Disk /dev/mapper/vg_main-lv_mysql: 158.4 GB, 158385307648 bytes
    255 heads, 63 sectors/track, 19255 cylinders
    Units = cylinders of 16065 * 512 = 8225280 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0x00000000
    
    Disk /dev/mapper/vg_main-lv_mysql doesn't contain a valid partition table
    

    However I'm not able to extend the physical volume to allocate the new space for LVM on the guest machine (/dev/mapper/vg_main-lv_mysql):

    # pvresize -v /dev/vda2
    Using physical volume(s) on command line
    Archiving volume group "vg_main" metadata (seqno 17).
    Resizing volume "/dev/vda2" to 334516224 sectors.
    No change to size of physical volume /dev/vda2.
    Updating physical volume "/dev/vda2"
    Creating volume group backup "/etc/lvm/backup/vg_main" (seqno 18).
    Physical volume "/dev/vda2" changed
    1 physical volume(s) resized / 0 physical volume(s) not resized
    
  • Answers
  • Chopper3

    Falk's right that you can resize the partition but a potentially safer way, and one that generally works without reboots would be to use parted to create a new partition, then create a new PV, add it to the VG, then extend the LV and finally resize2fs the FS.

    Just wanted you to be aware there's more than one way.

  • Falk Stern

    You need to resize the partition /dev/vda2 as well, as your physical volume resides in a partition. You can use parted to resize the partition online. When you have resized the partition you can resize the pv with pvresize and afterwards the LV with lvextend.

    Best,

    Falk

  • Luca G.

    Adding a new physical volume will increase fragmentation, also it's not something that you can do on a regular basis or you will end up with too many PVs.

    Increasing the size of /dev/vda2 so that it covers the (currently) unpartitioned space is the correct way to go. If you look at your partition table, /dev/vda2 is only 160GB large, while the disk is 216GB.

    There is a nifty tool called virt-resize (part of the libguestfs tools) which does exactly what you need.

    It must be used on the KVM host itself, not inside the guest.

    If the KVM host is running Debian wheezy or a later version, you can install this tool with:

    apt-get install libguestfs-tools
    apt-get update (without this, update-guestfs-appliance might fail)
    update-guestfs-appliance
    

    If you are using another distribution, refer to http://libguestfs.org/guestfs-faq.1.html#binaries

    Assuming that the name of the LV which contains the guest is /dev/vg/guest, you must run:

    lvrename /dev/vg/guest /dev/vg/guest-backup
    lvcreate -n guest -L 200G /dev/vg
    virt-resize /dev/vg/guest-backup /dev/vg/guest --expand /dev/vda2 
    

    virt-resize will copy all the data from the old LV to the new LV and extend the partition /dev/vda inside the LV. Of course this assumes that you have 200GB available in the vg of the KVM host.

    If you don't, then you must do as Chopper3 suggested: update the partition table of the guest so that the "last" sector of partition /dev/vda2 is the last sector of /dev/vda.


  • Related Question

    linux - Resizing Xen guests using LVM
  • z0mbix

    I have a RHEL 5.4 server running as a Xen Dom0, and wish to install several RHEL 5.4 DomU guests using LVM as the guest disks. I have created the following two LVs:

    xen-test02-root  VM-VG -wi-a-   6.00G
    xen-test02-swap  VM-VG -wi-a- 512.00M
    

    I used the custom partitioning option when installing the guest so no LVM is used in the guest, only 2 disks. One for / (xvda) and one for swap (xvdb).

    This all works fine, but now I wish to test extending the root partition. So far, I have tried using lvextend from the Dom0. This works:

    # lvextend -L +4GB /dev/VM-VG/xen-test02-root
      Extending logical volume xen-test02-root to 10.00 GB
      Logical volume xen-test02-root successfully resized
    

    fdisk shows that the disk is now 10.7GB:

    # fdisk -l /dev/VM-VG/xen-test02-root
    
    Disk /dev/VM-VG/xen-test02-root: 10.7 GB, 10737418240 bytes
    255 heads, 63 sectors/track, 1305 cylinders
    Units = cylinders of 16065 * 512 = 8225280 bytes
    
                         Device Boot      Start         End      Blocks   Id  System
    /dev/VM-VG/xen-test02-root1   *           1         783     6289416   83  Linux
    

    I now wish to extend the partition on that disk with parted:

    (parted) print
    
    Model: Linux device-mapper (dm)
    Disk /dev/mapper/VM--VG-xen--test02--root: 10.7GB
    Sector size (logical/physical): 512B/512B
    Partition Table: msdos
    
    Number  Start   End     Size    Type     File system  Flags
     1      32.3kB  6440MB  6440MB  primary  ext3         boot
    
    (parted) resize 1 32.3kB 10.7GB
    Error: File system has an incompatible feature enabled.
    (parted)
    

    Any clues as to what I'm doing wrong? Is parted the best tool to resize partitons? Should I be using LVM differently for Xen guests?

    Many thanks, z0mbix


  • Related Answers
  • Aleksandar Ivanisevic

    Your problem here is that you can't resize ext3 partition with parted. you have to remove the journal (turning ext3 into ext2) and then resize.

    see this for more info

    http://www.hermann-uwe.de/blog/resizing-ext3-partitions-with-parted

  • womble

    Why are you partitioning the LV, instead of just using it directly? Also, if you are going to be manipulating the partition table, it's best to do it in the guest. Worst, it looks like you might be trying to fiddle with the partition table in the dom0 while the domU is still running... dangerous.

    My simple recipe for resizing a domU disk, which I've done probably in excess of a hundred times by now, is to have the domUs with the LV as the full root partition (xvda1) and then running:

    lvextend -L+NG -n domu-root vg
    xm shutdown -w domu
    xm create domu
    ssh domu resize2fs /dev/xvda1
    

    And voila, all done. For non-root filesystems, you can just detach/reattach (useful for swap, in particular), but root needs the reboot.

  • Chris S

    In your XEN config, don't attach the LV to xvda, attach it to something like xvda1 etc. The xvda device in your domU won't exist, but your domU will still see /dev/xvda1 as a valid partition.