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 _______________________________________________ virt mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/virt
