(In reply to comment #0)
> QEMU is expected to eventually grow support for online resizing of block
> devices, both for virtio-blk and scsi backends, as described in
> https://bugzilla.redhat.com/show_bug.cgi?id=515775
> 
> One of the current viable solutions is offline resizing via libguestfs.
> Libvirt needs to control this feature.

Just to make sure we're all clear on what's being requested--this RFE is for libvirt control of online resizing, not for control of the offline process using libguestfs, right?

Yes, this is for *live* volume resizing.

Yes, precisely.

I should have said "alternatives" where I said "solutions" in the original description. Re-reading it, I noticed it does sounds confusing. Sorry about that.

(In reply to comment #0)
> QEMU is expected to eventually grow support for online resizing of block
> devices, both for virtio-blk and scsi backends, as described in
> https://bugzilla.redhat.com/show_bug.cgi?id=515775
> 
> One of the current viable solutions is offline resizing via libguestfs.
> Libvirt needs to control this feature.

Has qemu grown the required support?

Glauber, any update on the qemu support?

Since RHEL 6.1 External Beta has begun, and this bug remains 
unresolved, it has been rejected as it is not proposed as an 
exception or blocker.

Red Hat invites you to ask your support representative to 
propose this request, if appropriate and relevant, in the 
next release of Red Hat Enterprise Linux.

(In reply to comment #8)
> Moving to 6.3 as the underlying qemu functionality has moved to 6.3.

Hello Dave,

515775 has been fixed and released with 6.1, do we need to wait on 677219 (win-virtio) or could we push this forwards for Linux only guests in 6.2?

I've added sfdc case 00332497 to this (RHEV RFE for online disk resize) that depends on this.

Thanks,

Lee

patches posted to upstream, but it might not be included into 6.2.

http://www.redhat.com/archives/libvir-list/2011-July/msg01788.html

patches committed to upstream:

https://www.redhat.com/archives/libvir-list/2011-November/msg01570.html

Verify this bug with :
libvirt-0.9.9-1.el6.x86_64

1）#virsh dumpxml q2
...
<disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none'/>
      <source file='/var/lib/libvirt/images/q2.img'/>
      <target dev='hda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>
...

2）# qemu-img info /var/lib/libvirt/images/q2.img
image: /var/lib/libvirt/images/q2.img
file format: qcow2
virtual size: 7.0G (7516192768 bytes)
disk size: 1.5G
cluster_size: 65536



3) resize guest's block 
virsh # qemu-monitor-command q2 block_resize  drive-virtio-disk0  10G --hmp 



4) check disk in the guest 

# cat /proc/partitions 
major minor  #blocks  name

 252        0   10485760 vda
 252        1     512000 vda1
 252        2    6827008 vda2
 253        0    5808128 dm-0
 253        1    1015808 dm-1

5）  in the host   check the image size 

# qemu-img  info /var/lib/libvirt/images/q2.img
image: /var/lib/libvirt/images/q2.img
file format: qcow2
virtual size: 10G (10737418240 bytes)
disk size: 1.5G
cluster_size: 65536

This functionality needs to be tested with virsh commands, not with qemu command passthrough, so I'm putting it back ON_QA.

See also this patch from bug 796526, which makes it possible to do block resize on a byte rather than KiB boundary.
http://post-office.corp.redhat.com/archives/rhvirt-patches/2012-March/msg01042.html

Verify this bug with :
libvirt-0.9.10-4.el6.x86_64

#virsh dumpxml r 
...
  <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none'/>
      <source file='/var/lib/libvirt/images/mig-qcow2.img'/>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </disk>
...

Before resize check disk in guest 
# fdisk -l

Disk /dev/vda: 12.3 GB, 12288000000 bytes
...


# virsh blockresize --domain r --path /var/lib/libvirt/images/mig-qcow2.img --size 15000000
Block device '/var/lib/libvirt/images/mig-qcow2.img' is resized

After resize check disk in the guest 

# cat /proc/partitions 
major minor  #blocks  name

 252        0   15000000 vda
 252        1     512000 vda1
 252        2    7875584 vda2
 253        0    6856704 dm-0
 253        1    1015808 dm-1

Great, thanks.

Did you verify the output of "fdisk -l" in guest after the resize. One bz reported that if virtio disk as in use during resize in guest, then "fdisk -l" does not see the updated size. Though "cat /proc/partitions" seem to be reflecting the new size.

BZ: 693940

(In reply to comment #22)
> Did you verify the output of "fdisk -l" in guest after the resize. One bz
> reported that if virtio disk as in use during resize in guest, then "fdisk -l"
> does not see the updated size. Though "cat /proc/partitions" seem to be
> reflecting the new size.
> 
> BZ: 693940

Hi，Vivek

We verify this bug with windows guest , it can resize disk online  and can use enlarge space,so libvirt and qemu-kvm work well .
About linux guest because kernel's bug 693940 , 'fdisk' command can not get updated disk space and can not use enlarge resized space, but we can check it with  "cat /proc/partitions" after resize disk and this bug depends on: 	677219 515775 669744  all verify with kernel's fdisk bug .
so we will keep this bug in "Verified"

Wenlong

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2012-0748.html