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