Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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
share|improve this question

3 Answers 3

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

share|improve this answer

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.

share|improve this answer
    
This way I will have to add another LVM partition (disk) for this guest on a hypervisor but I think it's a safer way indeed, rather than extending the existing LVM partition allocated for this virtual machine. BTW. I found this tutorial from the link below where one of the steps is to remove existing partition to add the new one with a new size but I'm not sure if this is safe? howtoforge.com/linux_resizing_ext3_partitions –  HTF May 9 '12 at 11:07
    
It's really a 50/50 kind of thing, often there's not just one single answer - just wanted you to be aware. –  Chopper3 May 9 '12 at 11:25

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.