Bug 1253754 - libvirt reports physical=0 for COW2 volumes on block storage
Summary: libvirt reports physical=0 for COW2 volumes on block storage
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: rawhide
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1250982
Blocks: 1154205 1253756 1419790 1419791
TreeView+ depends on / blocked
 
Reported: 2015-08-14 15:28 UTC by Nir Soffer
Modified: 2017-02-07 04:15 UTC (History)
21 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1250982
Environment:
Last Closed: 2015-10-06 19:14:27 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Comment 2 Peter Krempa 2015-08-17 14:44:05 UTC
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)

  block.1.name=vda
  block.1.path=/rhev/data-center/00000001-0001-0001-0001-0000000002ae/e1f383a6-7496-425f-bb47-c9310dbdf821/images/bfa8a4a1-c7a4-4c05-9047-87f592870a98/0a82037a-a70d-4173-95c3-a85c62337e55
  block.1.rd.reqs=5359
  block.1.rd.bytes=99524096
  block.1.rd.times=11901668378
  block.1.wr.reqs=1786
  block.1.wr.bytes=5670400
  block.1.wr.times=18790464626
  block.1.fl.reqs=88
  block.1.fl.times=8583220632
  block.1.allocation=952929792
  block.1.capacity=4294967296

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'/>
      <backingStore/>
      <target dev='vda' bus='virtio'/>
      <serial>bfa8a4a1-c7a4-4c05-9047-87f592870a98</serial>
      <boot order='1'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </disk>


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 libvirt.org (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 <pkrempa>
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
    more.
    
    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 19:14:27 UTC
This patch is in libvirt-1.2.18.1-1.fc23 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.