This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1253754 - libvirt reports physical=0 for COW2 volumes on block storage
libvirt reports physical=0 for COW2 volumes on block storage
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
Unspecified Unspecified
urgent Severity urgent
: ---
: ---
Assigned To: Libvirt Maintainers
Fedora Extras Quality Assurance
: Regression
Depends On: 1250982
Blocks: 1154205 1253756 1419790 1419791
  Show dependency treegraph
Reported: 2015-08-14 11:28 EDT by Nir Soffer
Modified: 2017-02-06 23:15 EST (History)
21 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1250982
Last Closed: 2015-10-06 15:14:27 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Comment 2 Peter Krempa 2015-08-17 10:44:05 EDT
Description of problem:
Found installing oVirt 3.6.0 (development snapshot).
I'm not sure if it is libvirt or QEMU issue.

I created a VM using block storage (LVM) and thin-provisioned image (QCOW2).
Libvirt misreport the "physical" size of the volume, breaking the transparent volume resizing flow in oVirt.

I was building a fresh 3.6.0 devel environment (vdsm/engine from git) on RHEL 7.2 to check
virt patches. I'm using ISCSI storage and thin provisioned volumes.

The automatic volume extension flow seems broken, meaning the space eventually is exhausted
and the VM goes paused.

The problem seems to be that libvirt always report physical=0 for the disk. After a freshly started VM:

BENji> 09:33:20 root [~]$ virsh -r domblkinfo 2 vda
Capacity:       4294967296
Allocation:     952929792
Physical:       0

Same with bulk stats (excerpt)

The same image and same VM run using a RHEL7.1 host:

using libvirt 1.2.8-16.el7_1.3  and qemu-kvm-rhev 10:2.1.2-23.el7_1.7 
HOji> 10:25:24 root [~]$ virsh -r domblkinfo 2 vda
Capacity:       4294967296
Allocation:     1063390720
Physical:       2147483648

Here's how the disk xml looks like:

    <disk type='block' device='disk' snapshot='no'>
      <driver name='qemu' type='qcow2' cache='none' error_policy='stop' io='native'/>
      <source dev='/rhev/data-center/00000001-0001-0001-0001-0000000002ae/e1f383a6-7496-425f-bb47-c9310dbdf821/images/bfa8a4a1-c7a4-4c05-9047-87f592870a98/0a82037a-a70d-4173-95c3-a85c62337e55'/>
      <target dev='vda' bus='virtio'/>
      <boot order='1'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>

Version-Release number of selected component (if applicable):
libvirt 1.2.17-2.el7 
qemu-kvm-rhev 10:2.3.0-15.el7

How reproducible:
100% of my tries. Seems to behave the same with vanilla libvirt 1.2.17 from (rebuilt rpms from sources)

Steps to Reproduce:
1. create a VM with QCOW2 virtio disk on block storage. I used a 4GB thin provisioned image (2GB actually reserved, see good domblkinfo output above)
2. run out of the space on the volume. I just installed centos7 using all the provided defaults, then tried to run "yum -y" update
3. check the reported pyshical allocation using e.g. virsh domblkinfo

Actual results:
physical is always zero

Expected results:
physical reports the right value

--- Additional comment from Peter Krempa on 2015-08-07 07:38:12 EDT ---

Fixed upstream:

commit 8dc27259255b79758367789ed272e909bdb56735
Author: Peter Krempa <>
Date:   Fri Aug 7 11:01:49 2015 +0200

    qemu: Fix reporting of physical capacity for block devices
    Qemu reports physical size 0 for block devices. As 15fa84acbb55ebfee6a4
    changed the behavior of qemuDomainGetBlockInfo to just query the monitor
    this created a regression since we didn't report the size correctly any
    This patch adds code to refresh the physical size of a block device by
    opening it and seeking to the end and uses it both in
    qemuDomainGetBlockInfo and also in qemuDomainGetStatsOneBlock that was
    broken since it was introduced in this respect.
Comment 3 Cole Robinson 2015-10-06 15:14:27 EDT
This patch is in libvirt- and libvirt-1.2.20-1.fc24, so closing

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