RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1473706 - RHEL7.4: virDomainGetBlockInfo always returns alloc=0 on block storage
Summary: RHEL7.4: virDomainGetBlockInfo always returns alloc=0 on block storage
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.4-Alt
Hardware: All
OS: Unspecified
urgent
urgent
Target Milestone: rc
: ---
Assignee: John Ferlan
QA Contact: Virtualization Bugs
Jiri Herrmann
URL:
Whiteboard:
Depends On: 1467826
Blocks: 1470127
TreeView+ depends on / blocked
 
Reported: 2017-07-21 13:15 UTC by Jiri Denemark
Modified: 2017-11-09 11:26 UTC (History)
4 users (show)

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.
Clone Of: 1467826
Environment:
Last Closed: 2017-11-09 11:26:03 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2017:3174 0 normal SHIPPED_LIVE libvirt enhancement update 2017-11-09 16:12:36 UTC

Description Jiri Denemark 2017-07-21 13:15:07 UTC 
+++ 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-07 03:15:04 UTC 
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.
Comment 6 errata-xmlrpc 2017-11-09 11:26:03 UTC 
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.

https://access.redhat.com/errata/RHEA-2017:3174
Note You need to log in before you can comment on or make changes to this bug.