Bug 1473706 - RHEL7.4: virDomainGetBlockInfo always returns alloc=0 on block storage
RHEL7.4: virDomainGetBlockInfo always returns alloc=0 on block storage
Status: VERIFIED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt (Show other bugs)
7.4-Alt
All Unspecified
urgent Severity urgent
: rc
: ---
Assigned To: John Ferlan
Virtualization Bugs
Jiri Herrmann
: Regression, ZStream
Depends On: 1467826
Blocks: 1470127
  Show dependency treegraph
 
Reported: 2017-07-21 09:15 EDT by Jiri Denemark
Modified: 2017-09-06 23:15 EDT (History)
4 users (show)

See Also:
Fixed In Version: libvirt-3.2.0-16.el7a
Doc Type: Bug Fix
Doc Text:
Cause: Editing error while making changes to the code. Consequence: For a block device, virDomainGetBlockInfo always returned 0 for the allocation value of a sparse target device for an active QEMU domain. Fix: Remove the extraneous line. Result: The allocation value for a sparse block device target for an active QEMU domain will have the correct value as determined at the time of statistic collection.
Story Points: ---
Clone Of: 1467826
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jiri Denemark 2017-07-21 09:15:07 EDT
+++ This bug was initially created as a clone of Bug #1467826 +++

Description of problem:
oVirt: 
When the guest disk has to be extended, Libvirt doesn't propagate the request to the upper layered component, in our case - VDSM.

Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux Server 7.4 (Maipo)
libvirt-daemon-driver-storage-core-3.2.0-14.el7.x86_64
libvirt-daemon-driver-storage-logical-3.2.0-14.el7.x86_64
libvirt-daemon-driver-secret-3.2.0-14.el7.x86_64
libvirt-libs-3.2.0-14.el7.x86_64
libvirt-daemon-driver-storage-scsi-3.2.0-14.el7.x86_64
libvirt-daemon-3.2.0-14.el7.x86_64
libvirt-daemon-driver-network-3.2.0-14.el7.x86_64
libvirt-daemon-config-nwfilter-3.2.0-14.el7.x86_64
libvirt-daemon-driver-storage-gluster-3.2.0-14.el7.x86_64
libvirt-daemon-driver-storage-3.2.0-14.el7.x86_64
libvirt-daemon-driver-interface-3.2.0-14.el7.x86_64
libvirt-daemon-kvm-3.2.0-14.el7.x86_64
libvirt-daemon-driver-qemu-3.2.0-14.el7.x86_64
libvirt-daemon-driver-storage-mpath-3.2.0-14.el7.x86_64
libvirt-daemon-driver-storage-iscsi-3.2.0-14.el7.x86_64
libvirt-daemon-driver-nodedev-3.2.0-14.el7.x86_64
libvirt-python-3.2.0-3.el7.x86_64
libvirt-daemon-driver-storage-rbd-3.2.0-14.el7.x86_64
libvirt-daemon-driver-nwfilter-3.2.0-14.el7.x86_64
libvirt-daemon-driver-storage-disk-3.2.0-14.el7.x86_64
libvirt-lock-sanlock-3.2.0-14.el7.x86_64
libvirt-client-3.2.0-14.el7.x86_64
qemu-kvm-rhev-2.6.0-28.el7_3.9.x86_64
ipxe-roms-qemu-20170123-1.git4e85b27.el7.noarch
qemu-kvm-tools-rhev-2.6.0-28.el7_3.9.x86_64
qemu-img-rhev-2.6.0-28.el7_3.9.x86_64
libvirt-daemon-driver-qemu-3.2.0-14.el7.x86_64
qemu-kvm-common-rhev-2.6.0-28.el7_3.9.x86_64
sanlock-python-3.5.0-1.el7.x86_64
sanlock-lib-3.5.0-1.el7.x86_64
sanlock-3.5.0-1.el7.x86_64
selinux-policy-3.13.1-165.el7.noarch
vdsm-4.19.20-1.el7ev.x86_64
lvm2-2.02.171-8.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
In oVirt: 
1. Create a guest with thin provisioned disk resides on a block-based storage (VDSM creates a 1G LV)
2. Perform write operation to the guest storage (could be acheived by simply installing OS on the guest)


Actual results:
No allocation request from Libvirt to VDSM for extending the guest disk

Expected results:
Libvirt should detect that the guest storage is about to run out of space and ask for allocation.
Comment 4 Dan Zheng 2017-09-06 23:15:04 EDT
Test packages:

libvirt-3.2.0-21.el7a.ppc64le
qemu-kvm-2.9.0-22.el7a.ppc64le
kernel-4.11.0-28.el7a.ppc64le

Steps:
1. Prepare scsi disk
# lsblk
NAME                  MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sdb                     8:16   0  1000M  0 disk  ===>scsi disk
sda                     8:0    0 279.4G  0 disk 
├─sda2                  8:2    0     1G  0 part /boot
├─sda3                  8:3    0 278.4G  0 part 
│ ├─rhel7--pegas-swap 253:1    0    16G  0 lvm  [SWAP]
│ ├─rhel7--pegas-home 253:2    0 164.8G  0 lvm  /home
│ └─rhel7--pegas-root 253:0    0  97.7G  0 lvm  /
└─sda1                  8:1    0     4M  0 part 

2. Create a partition on /dev/sdb
# lsblk
NAME                  MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sdb                     8:16   0  1000M  0 disk 
└─sdb1                  8:17   0   992M  0 part 
...
3. Create PG,VG,LV
# pvcreate /dev/sdb1
  Physical volume "/dev/sdb1" successfully created.
# vgcreate vg /dev/sdb1
  Volume group "vg" successfully created
# lvcreate -n lv2 -L 800M vg
  Logical volume "lv2" created.
# lvs vg/lv2
  LV   VG Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lv2  vg -wi-a----- 800.00m    

4.Check
# fdisk -l
...
Disk /dev/sdb: 1048 MB, 1048576000 bytes, 2048000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 8388608 bytes
Disk label type: dos
Disk identifier: 0x7f4c4b0a

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1           16384     2047999     1015808   83  Linux

Disk /dev/mapper/vg-lv2: 838 MB, 838860800 bytes, 1638400 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 8388608 bytes


5. Attach the LV to a running guest
# virsh attach-disk vm2 /dev/mapper/vg-lv2 vdb
Disk attached successfully
<In VM> # fdisk -l
Disk /dev/vdb: 838 MB, 838860800 bytes, 1638400 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

6. # virsh domblkinfo vm2 vdb
Capacity:       838860800
Allocation:     0
Physical:       838860800

7. Write some data in VM and check domblkinfo:
(in VM)# # dd if=/dev/urandom of=/dev/vdb bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 4.84527 s, 111 MB/s

8. Check in host
# virsh domblkinfo vm2 vdb
Capacity:       838860800
Allocation:     536870912  <=== Same with written
Physical:       838860800

9. Extend the lv and check domblkinfo
# lvextend --size +100M vg/lv2
  Size of logical volume vg/lv2 changed from 800.00 MiB (200 extents) to 900.00 MiB (225 extents).
  Logical volume vg/lv2 successfully resized.

# virsh domblkinfo vm2 vdb
Capacity:       838860800
Allocation:     536870912  <=== no change
Physical:       943718400

All is pass.

Note You need to log in before you can comment on or make changes to this bug.