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 817219 - Don't allow to define multiple pools with the same target
Summary: Don't allow to define multiple pools with the same target
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.3
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Osier Yang
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-28 05:49 UTC by Alex Jia
Modified: 2013-02-21 07:12 UTC (History)
8 users (show)

Fixed In Version: libvirt-0.9.13-3.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-21 07:12:27 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0276 0 normal SHIPPED_LIVE Moderate: libvirt security, bug fix, and enhancement update 2013-02-20 21:18:26 UTC

Description Alex Jia 2012-04-28 05:49:45 UTC
Description of problem:
This issue originally is reported by users, for example, there are 3 pool XML files({A,B,C}.xml) and 2 pools(A.xml, B.xml) source path specify the same target, then there are different target for rest of 1 pool(C.xml). when I define pool A.xml and B.xml, as expected, libvirt raises "Storage source conflict with pool: 'xx'", however, B.xml can be successfully defined after I defined C.xml. 
    

Version-Release number of selected component (if applicable):
# rpm -q libvirt
libvirt-0.9.10-14.el6.x86_64

How reproducible:
always

Steps to Reproduce:

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

# virsh pool-define B.xml 
error: Failed to define pool from B.xml
error: operation failed: Storage source conflict with pool: 'B'

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

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


# virsh pool-dumpxml A.xml
<pool type='iscsi'>
  <name>A</name>
  <uuid>ba58183c-9cff-022a-4204-b161cd67a750</uuid>
  <capacity unit='bytes'>0</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>
  <source>
    <host name='192.168.58.160'/>
    <device path='iqn.2011-01.com.usi:storage.iscsi1'/>
  </source>
  <target>
    <path>/dev/disk/by-path</path>
    <permissions>
      <mode>0700</mode>
      <owner>-1</owner>
      <group>-1</group>
    </permissions>
  </target>
</pool>

# virsh pool-dumpxml B.xml
<pool type='iscsi'>
  <name>B</name>
  <uuid>d2cd5eb1-32bc-833f-c93a-f56b0b85853c</uuid>
  <capacity unit='bytes'>0</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>
  <source>
    <host name='192.168.58.160'/>
    <device path='iqn.2011-01.com.usi:storage.iscsi1'/>
  </source>
  <target>
    <path>/dev/disk/by-path</path>
    <permissions>
      <mode>0700</mode>
      <owner>-1</owner>
      <group>-1</group>
    </permissions>
  </target>
</pool>

# virsh pool-dumpxml C.xml
<pool type='iscsi'>
  <name>C</name>
  <uuid>f145fcaa-d53d-a4f1-67bb-3a28831250b5</uuid>
  <capacity unit='bytes'>0</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>
  <source>
    <host name='192.168.58.160'/>
    <device path='iqn.2011-01.com.usi:storage.iscsi2'/>
  </source>
  <target>
    <path>/dev/disk/by-path</path>
    <permissions>
      <mode>0700</mode>
      <owner>-1</owner>
      <group>-1</group>
    </permissions>
  </target>
</pool>


Actual results:
There are the same target for Pool A and B, but I can successfully define B if I define a other Pool C(different target) between A and B.

Expected results:
Don't allow define a pool with the same target.

Additional info:
In addition, I can successfully define a domain with the same source file now, it probably is a common issues.

Comment 1 Alex Jia 2012-04-28 06:13:57 UTC
(In reply to comment #0)
> 
> Additional info:
> In addition, I can successfully define a domain with the same source file now,
> it probably is a common issues.

I'm considering whether we need also to use sanlock to protect the underlying
storage just like avoiding 2 domain concurrently access the same source file.

However, it seems pool's case is different with domain, libvirt give a
judgement for defining the same target pool, indeed, we can see a expected
error message "Storage source conflict with pool: 'xxx'", however, if we break
this process then insert to define another a pool with different target,
libvirt allow to define the same target pool again.

Comment 2 Osier Yang 2012-04-28 08:28:12 UTC
Patch posted to upstream:

https://www.redhat.com/archives/libvir-list/2012-April/msg01491.html

BTW. The bug title should be changed, it sounds like a feature request.

Comment 3 Alex Jia 2012-04-28 09:19:06 UTC
(In reply to comment #2)
> 
> BTW. The bug title should be changed, it sounds like a feature request.
Yeah, I have changed bug title. thanks.

Comment 4 Osier Yang 2012-04-30 13:14:06 UTC
commit 980f12be7221b07e569fed24b372ea00c52d9511
Author: Osier Yang <jyang>
Date:   Sat Apr 28 16:18:44 2012 +0800

    storage: Break out the loop if duplicate pool is found
    
    It doesn't break out the "for" loop even if duplicate pool is
    found, and thus the "matchpool" could be overriden as NULL again
    if there is different pool afterwards.
    
    To address the problem in libvirt-user list:
    
    https://www.redhat.com/archives/libvirt-users/2012-April/msg00150.html

Commit pushed in upstream.

Comment 6 Osier Yang 2012-05-28 09:01:16 UTC
Per comment 4, move to POST.

Comment 9 zhe peng 2012-07-25 02:57:30 UTC
can reproduce this with libvirt-0.9.10-16.el6.x86_64

verify with:libvirt-0.9.13-3.el6.x86_64
 step:
   1:prepare a.xml b.xml c.xml as bug description
   2:
    #virsh pool-define a.xml
    Pool A defined from a.xml
   
    # virsh pool-define b.xml
    error: Failed to define pool from b.xml
    error: operation failed: Storage source conflict with pool: 'A'
   
    # virsh pool-define c.xml
    Pool C defined from c.xml

    # virsh pool-define b.xml
    error: Failed to define pool from b.xml
    error: operation failed: Storage source conflict with pool: 'A'
  the pool with the same target can't define.verification passed.

Comment 10 errata-xmlrpc 2013-02-21 07:12:27 UTC
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.

http://rhn.redhat.com/errata/RHSA-2013-0276.html


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