Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

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 673455

Summary:	Capacity and allocation sizes display much bigger than defined in LVM based volumes
Product:	Red Hat Enterprise Linux 6	Reporter:	Min Zhan <mzhan>
Component:	libvirt	Assignee:	Osier Yang <jyang>
Status:	CLOSED NOTABUG	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.1	CC:	dallan, dyuan, eblake, jyang, llim, mzhan, xen-maint, yoyzhang
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-01-28 10:10:25 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Min Zhan 2011-01-28 09:38:37 UTC

Description of problem:
In LVM based storage, create a volume and dump info, found the capacity and allocation values are more bigger than the defined values.

Version-Release number of selected component (if applicable):
# uname -a
Linux dhcp-65-85.nay.redhat.com 2.6.32-99.el6.x86_64 #1 SMP Fri Jan 14 10:46:00
EST 2011 x86_64 x86_64 x86_64 GNU/Linux

libvirt-0.8.7-4.el6.x86_64
kernel-2.6.32-99.el6.x86_64
qemu-kvm-0.12.1.2-2.132.el6.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Create a LVM storage pool
# cat test.xml 
     <pool type='logical'>
       <name>test</name>
       <source>
         <name>test</name>
         <format type='lvm2'/>
         <device path='/dev/sda5'/>
       </source>
       <target>
         <path>/dev/test</path>
       </target>
     </pool>

# virsh pool-define test.xml 
Pool test defined from test.xml

# virsh pool-build test
Pool test built

# virsh pool-start test
Pool test started

# virsh pool-list 
Name                 State      Autostart 
-----------------------------------------
default              active     yes       
test                 active     no        

2. Create a volume in this storage
# cat vol1.xml 
<volume>
            <name>vol1</name>
            <capacity>2147484672</capacity>
            <allocation>2147484672</allocation>
            <target>
                <format type='raw'/>
            </target>
        </volume>

# virsh vol-create test vol1.xml 
Vol vol1 created from vol1.xml

# virsh vol-dumpxml --pool test vol1
<volume>
  <name>vol1</name>
  <key>5IDQQg-Lhfg-z9iA-jau4-I2GF-vuK8-XBSdAG</key>
  <source>
    <device path='/dev/sda5'>
      <extent start='2151677952' end='4303355904'/>
    </device>
  </source>
  <capacity>2151677952</capacity>
  <allocation>2151677952</allocation>
  <target>
    <path>/dev/test/vol1</path>
    <permissions>
      <mode>0600</mode>
      <owner>0</owner>
      <group>6</group>
      <label>system_u:object_r:fixed_disk_device_t:s0</label>
    </permissions>
  </target>
</volume>


3. Some debug info about actual allocated sizes:
....
Jan 29 00:15:35 dhcp-65-85 libvirtd: 00:15:35.822: 26681: warning : storageVolumeCreateXML:1301 :  voldef->capacity: 2147484672
Jan 29 00:15:35 dhcp-65-85 libvirtd: 00:15:35.822: 26681: warning : virStorageBackendLogicalCreateVol:607 :  vol->capacity: 2147484672
Jan 29 00:15:35 dhcp-65-85 libvirtd: 00:15:35.822: 26681: warning : virStorageBackendLogicalCreateVol:612 :  capacity: 2097153
....

  
Actual results:
2151677952 / 1024= 2101248 kb display in volume dumpxml which is much bigger than 2097153 kb. 

Expected results:
The expected result in volume dumpxml should be as debug info: 2147484672 /1024=2097153 kb.

Additional info:

This bug can also be reproduced with following xml with different size 2147483649.

# cat vol.xml 
    <volume>
            <name>vol</name>
            <capacity>2147483649</capacity>
            <allocation>2147483649</allocation>
            <target>
                <format type='raw'/>
            </target>
        </volume>

# virsh vol-create test vol.xml 
Vol vol created from vol.xml

# virsh vol-dumpxml --pool test vol
<volume>
  <name>vol</name>
  <key>rf2n5V-GkuP-N3p5-ddUQ-21q5-y9TH-dFA6Y0</key>
  <source>
    <device path='/dev/sda5'>
      <extent start='0' end='2151677952'/>
    </device>
  </source>
  <capacity>2151677952</capacity>
  <allocation>2151677952</allocation>
  <target>
    <path>/dev/test/vol</path>
    <permissions>
      <mode>0600</mode>
      <owner>0</owner>
      <group>6</group>
      <label>system_u:object_r:fixed_disk_device_t:s0</label>
    </permissions>
  </target>
</volume>

Comment 1 Osier Yang 2011-01-28 10:10:25 UTC

libvirt uses lvcreate to create logical volume, and the command according to
above xml "vol.xml" is:

/sbin/lvcreate --name vol -L 2097153K /dev/test

Tried with above command directly:

[root@dhcp ~]# /sbin/lvcreate --name vol2 -L 2097153K /dev/test
  Rounding up size to full physical extent 2.00 GiB
  Logical volume "vol2" created


lvm> lvdisplay --units k
  --- Logical volume ---
  LV Name                /dev/test/vol2
  VG Name                test
  LV UUID                ECr9uN-bVX2-hQLD-c119-e72s-DWvT-QHAMha
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                2101248.00 KiB
  Current LE             513
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:2

lvm> lvdisplay
  --- Logical volume ---
  LV Name                /dev/test/vol2
  VG Name                test
  LV UUID                ECr9uN-bVX2-hQLD-c119-e72s-DWvT-QHAMha
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                2.00 GiB
  Current LE             513
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:2


So, we pass the correct size to lvcreate, and also gets correct size of the
volume, the problem here is "lvcreate" rounds up the size.

2 more examples:
---------------------------

[root@dhcp ~]# /sbin/lvcreate --name vol3 -L 2097152K /dev/test
  Logical volume "vol3" created
[root@dhcp ~]# /sbin/lvcreate --name vol4 -L 2097151K /dev/test
  Rounding up size to full physical extent 2.00 GiB
  Logical volume "vol4" created

And it's resonable for lvcreate doing like so, as if it rounds down the
capacity, there will be a bug for lvm (user will fail when trying to write to
the volume with the size he specified), just like
https://bugzilla.redhat.com/show_bug.cgi?id=670529 for libvirt. 

Thus, close it as NOTABUG.