Bug 1473706
| Summary: | RHEL7.4: virDomainGetBlockInfo always returns alloc=0 on block storage | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jiri Denemark <jdenemar> |
| Component: | libvirt | Assignee: | John Ferlan <jferlan> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | urgent | Docs Contact: | Jiri Herrmann <jherrman> |
| Priority: | urgent | ||
| Version: | 7.4-Alt | CC: | dzheng, gsun, jferlan, rbalakri |
| Target Milestone: | rc | Keywords: | Regression, ZStream |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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: | 2017-11-09 11:26:03 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1467826 | ||
| Bug Blocks: | 1470127 | ||
|
Description
Jiri Denemark
2017-07-21 13:15:07 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. 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 |