This breaks RHEV thin provisioning on block storage, and a regression
from earlier releases.

Can you check with permissive mode?

If it work with permissive mode, can get the related AVCs?
for example: ausearch -m AVC -ts today

can be reproduced on pure libvirt env. 
versions:
kernel-devel-3.10.0-302.el7.x86_64
libvirt-1.2.17-3.el7.x86_64
qemu-kvm-rhev-2.3.0-14.el7.x86_64


preparation:
I used a iscsi lun as block device (/dev/sdj) and a usb disk as block device (/dev/sdb), and both of them can reproduce this issue with following steps.

steps:
in host:
1. #qemu-img create -f qcow2 /dev/sdj 1G
Formatting '/dev/sdj', fmt=qcow2 size=1073741824 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16

2. #virsh destroy vm; virsh edit vm
Add folloiwng:
    <disk type='block' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source dev='/dev/sdj'/>
      <target dev='vdb' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
    </disk>

3. #virsh start vm
Domain vm started


in guest
4. #mkfs.xfs /dev/vdb
5. #mount /dev/vdb /mnt 
6. #cp /boot/* /mnt

in host:
7. # virsh domblkinfo vm vdb
Capacity:       1073741824
Allocation:     107412992
Physical:       0                         <====== physical size is zero

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.

(In reply to Peter Krempa from comment #6)
> Fixed upstream:

Thanks for the quick fix Peter!

According to https://apps.fedoraproject.org/packages/libvirt the broken version is 
available also in Fedora 23 (and probably in virt-preview on Fedora 22?). 

Should open a separate Fedora bug, or this fix is also backported to Fedora?

Jiri, can you check comment 8?

Yeah, file a separate Fedora bug.

Verified on:
libvirt-1.2.17-6.el7.x86_64
qemu-kvm-rhev-2.3.0-18.el7.x86_64

Steps:
1. prepared a iscsi lun
# lsscsi
...
[78:0:0:1]   disk    IET      VIRTUAL-DISK     0001  /dev/sdd      <=== An iscsi storage


2. # qemu-img create -f qcow2 /dev/sdd 1G
Formatting '/dev/sdd', fmt=qcow2 size=1073741824 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16


3. # qemu-img info /dev/sdd
image: /dev/sdd
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 0
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false


4. #virsh edit rhel1
add following segment. 
    <disk type='block' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source dev='/dev/sdd'/>
      <target dev='vdb' bus='virtio'/>
    </disk>

5. # virsh domblkinfo rhel1 vdb
Capacity:       1073741824
Allocation:     0
Physical:       1073741824


Login to guest
6. # fdisk -l
Disk /dev/vda: 1073 MB, 1073741824 bytes, 2097152 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


7. #mkfs.xfs /dev/vda

8. #mount /dev/vda /mnt

9. # dd if=/dev/zero of=/mnt/1G.file bs=1M count=1024
dd: error writing ‘/mnt/1G.file’: No space left on device
982+0 records in
981+0 records out
1029517312 bytes (1.0 GB) copied, 4.54759 s, 226 MB/s


Back to host
10. # virsh domblkinfo rhel1 vdb
Capacity:       1073741824
Allocation:     1040776704
Physical:       1073741824   <==== Physical size is correct as expect.

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://rhn.redhat.com/errata/RHBA-2015-2202.html

Peter hi,

Is this bug relevant in Fedora 23 ?

Thanks,

Fred

(In reply to Fred Rolland from comment #15)
> Peter hi,
> 
> Is this bug relevant in Fedora 23 ?

https://bugzilla.redhat.com/show_bug.cgi?id=1253754