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 1312181 - when creating vol with owner!=root and vol's allocation_size > pool's available_size, libvirt still created that vol even if an error produced.
Summary: when creating vol with owner!=root and vol's allocation_size > pool's availab...
Keywords:
Status: CLOSED DUPLICATE of bug 1260356
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.3
Hardware: x86_64
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Pavel Hrdina
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-26 01:34 UTC by yisun
Modified: 2016-03-01 13:36 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-03-01 13:36:52 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description yisun 2016-02-26 01:34:52 UTC
Description of problem:
when creating vol with owner!=root and vol's allocation_size > pool's available_size, libvirt still created that vol even if an error produced.

Version-Release number of selected component (if applicable):
kernel-3.10.0-350.el7.x86_64
qemu-kvm-rhev-2.3.0-31.el7_2.7
libvirt-1.3.1-1.el7

How reproducible:
100%

steps to reproduce:
1. having a dir pool as follow:
# virsh pool-dumpxml test-pool
<pool type='dir'>
  <name>test-pool</name>
  <uuid>849399e0-3f8b-4652-b003-8a421ad50c08</uuid>
  <capacity unit='bytes'>42141450240</capacity>
  <allocation unit='bytes'>31223828480</allocation>
  <available unit='bytes'>10917621760</available>
  <source>
  </source>
  <target>
    <path>/tmp/pool</path>
    <permissions>
      <mode>0755</mode>
      <owner>0</owner>
      <group>0</group>
      <label>unconfined_u:object_r:user_tmp_t:s0</label>
    </permissions>
  </target>
</pool>

# virsh pool-info test-pool
Name:           test-pool
UUID:           849399e0-3f8b-4652-b003-8a421ad50c08
State:          running
Persistent:     no
Autostart:      no
Capacity:       39.25 GiB
Allocation:     29.08 GiB
Available:      10.17 GiB   <=== left space is 10G

2. prepare a vol xml as follow, set the owner&group to 0 (root), and make sure the vol's allocation size is greater that the pool's available size:
# cat 200G_alloc_raw_root.vol
<volume type='file'>
  <name>200G_alloc.img</name>
  <source>
  </source>
<capacity>214748364800</capacity>  
<allocation>214748364800</allocation>  <!-- 200G -->
<target>
    <path>/tmp/pool/200G_alloc.img</path>
    <format type='raw'/>
    <permissions>
      <mode>0600</mode>
      <owner>0</owner>   <!-- root -->
      <group>0</group>
      <label>system_u:object_r:virt_image_t:s0</label>
    </permissions>
  </target>
</volume>


3. create vol with xml 200G_alloc_raw_root.vol
# virsh vol-create test-pool 200G_alloc_raw_root.vol
error: Failed to create vol from 200G_alloc_raw_root.vol
error: cannot allocate 214748364800 bytes in file '/tmp/pool/200G_alloc.img': No space left on device

4. check the vol in the test-pool
# virsh pool-refresh test-pool; virsh vol-list test-pool
Pool test-pool refreshed

 Name                 Path                                    
------------------------------------------------------------------------------
<==== nothing created as expected.

5. prepare anohter xml as follow and set the owner&group to 107(qemu), and make sure the vol's allocation size is greater that the pool's available size:
# cat 200G_alloc_raw_qemu.vol
<volume type='file'>
  <name>200G_alloc.img</name>
  <source>
  </source>
<capacity>214748364800</capacity>  
<allocation>214748364800</allocation>
<target>
    <path>/tmp/pool/200G_alloc.img</path>
    <format type='raw'/>
    <permissions>
      <mode>0600</mode>
      <owner>107</owner>   <!-- qemu -->
      <group>107</group>
      <label>system_u:object_r:virt_image_t:s0</label>
    </permissions>
  </target>
</volume>

6. try to create vol with xml 200G_alloc_raw_qemu.vol
# virsh vol-create test-pool 200G_alloc_raw_qemu.vol
error: Failed to create vol from 200G_alloc_raw_qemu.vol
error: cannot allocate 214748364800 bytes in file '/tmp/pool/200G_alloc.img': No space left on device

7. check the vol-list of test-pool
# virsh pool-refresh test-pool; virsh vol-list test-pool
Pool test-pool refreshed

 Name                 Path                                    
------------------------------------------------------------------------------
 200G_alloc.img       /tmp/pool/200G_alloc.img   <=== even if step 6 failed, img partially created.

# du -h /tmp/pool/200G_alloc.img
11G        /tmp/pool/200G_alloc.img  <=== even if step 6 failed, img partially created.

Actually result:
Step 6 created a img file.

Expected result:
Step 6 should not create img file as step 3 did.

Note:
The only difference of step 3 and step 6 is that the owner/group in the vols' xml files changed. (root vs. qemu)

Comment 1 Pavel Hrdina 2016-03-01 13:36:52 UTC
It may not seems to be a duplicate, but it uses the same function to remove file if something goes wrong.

*** This bug has been marked as a duplicate of bug 1260356 ***


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