On Wed, Jun 13, 2012 at 10:22 AM, Kevin Wolf wrote:
Never use qemu-img to modify an image that is in use by a VM, it might break the image. You need to use the qemu monitor of that VM to modify this image, which in your case means that you should probably use the proper libvirt interface, e.g. with virsh.
Kevin
ops .. I didn't keep this into consideration, as I only used qemu-img resize with powered off vm until now... So the disk was indeed brutally corrupted at next reboot... never mind. I reinstalled f17 guest from scratch. Now we are here:
f17 vm is running
on host: $ sudo qemu-img info /var/lib/libvirt/images/f17.img image: /var/lib/libvirt/images/f17.img file format: qcow2 virtual size: 8.0G (8589934592 bytes) disk size: 5.7G cluster_size: 65536
[g.cecchi@ope46 ~]$ sudo virsh blockresize f17 /var/lib/libvirt/images/f17.img 9G Block device '/var/lib/libvirt/images/f17.img' is resized
In guest the / filesystem is on lvm while /boot is on first partition: [root@f17 ~]# fdisk -l /dev/sda
Disk /dev/sda: 8589 MB, 8589934592 bytes 64 heads, 32 sectors/track, 8192 cylinders, total 16777216 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 Disk identifier: 0x0001e726
Device Boot Start End Blocks Id System /dev/sda1 * 2048 1026047 512000 83 Linux /dev/sda2 1026048 16777215 7875584 8e Linux LVM
[root@f17 ~]# echo 1 > /sys/block/sda/device/rescan
from dmesg output: [ 263.003897] sd 2:0:0:0: [sda] 18874368 512-byte logical blocks: (9.66 GB/9.00 GiB) [ 263.004344] sda: detected capacity change from 8589934592 to 9663676416
[root@f17 ~]# fdisk -l /dev/sda
Disk /dev/sda: 9663 MB, 9663676416 bytes 64 heads, 32 sectors/track, 9216 cylinders, total 18874368 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 Disk identifier: 0x0001e726
Device Boot Start End Blocks Id System /dev/sda1 * 2048 1026047 512000 83 Linux /dev/sda2 1026048 16777215 7875584 8e Linux LVM
I run fdisk and delete / create lvm partition bigger (as I usually do with plain partitions for filesystems on them); then
[root@f17 ~]# partprobe /dev/sda Error: Partition(s) 2 on /dev/sda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further changes.
[root@f17 ~]# kpartx /dev/sda sda1 : 0 1024000 /dev/sda 2048 sda2 : 0 17848320 /dev/sda 1026048
[root@f17 ~]# pvscan PV /dev/sda2 VG vg_f17 lvm2 [7.50 GiB / 0 free] Total: 1 [7.50 GiB] / in use: 1 [7.50 GiB] / in no VG: 0 [0 ]
[root@f17 ~]# pvresize /dev/sda2 Physical volume "/dev/sda2" changed 1 physical volume(s) resized / 0 physical volume(s) not resized
but nothing changes actually...
[root@f17 ~]# pvs PV VG Fmt Attr PSize PFree /dev/sda2 vg_f17 lvm2 a-- 7.50g 0
Is this a limitation of lvm layer? I noticed this kind of limitation also on VMware guests (with lsi logic virtual controller) where apparently I'm unable to inform lvm of the PV changed size.... I know that I can add another partition at the end of disk instead of resizing the existing one... but I'd prefer this latter... Thanks, Gianluca