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 1233003 - Manually created LVM is deleted by virsh vol-create-as if it is having the same name
Summary: Manually created LVM is deleted by virsh vol-create-as if it is having the sa...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.2
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: John Ferlan
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 1282283 (view as bug list)
Depends On: 1232170
Blocks: 1203710
TreeView+ depends on / blocked
 
Reported: 2015-06-18 02:57 UTC by Yang Yang
Modified: 2019-07-11 09:25 UTC (History)
8 users (show)

Fixed In Version: libvirt-1.3.1-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of: 1232170
Environment:
Last Closed: 2016-11-03 18:18:57 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2577 0 normal SHIPPED_LIVE Moderate: libvirt security, bug fix, and enhancement update 2016-11-03 12:07:06 UTC

Comment 2 Yang Yang 2015-06-18 06:38:24 UTC
This issue is also reproduced in rbd based pool

repro steps
1. define/start a rbd pool
<pool type='rbd'>
  <name>rbd</name>
  <uuid>89733e5d-2883-43ed-8046-8005129da0d1</uuid>
  <capacity unit='bytes'>139701780480</capacity>
  <allocation unit='bytes'>1262375227</allocation>
  <available unit='bytes'>70049128448</available>
  <source>
    <host name='10.66.5.219' port='6789'/>
    <host name='osd2.redhat.com' port='6789'/>
    <host name='osd3.redhat.com' port='6789'/>
    <name>libvirt-pool</name>
  </source>
</pool>

2. # virsh vol-list rbd
 Name                 Path                                    
------------------------------------------------------------------------------
 rbd1.img             libvirt-pool/rbd1.img                   
 rbd2.img             libvirt-pool/rbd2.img                   
 yy1.img              libvirt-pool/yy1.img                    
 yy2.img              libvirt-pool/yy2.img

3. manually create a image
# qemu-img create rbd:libvirt-pool/haha.img:mon_host=10.66.4.147 100M
Formatting 'rbd:libvirt-pool/haha.img:mon_host=10.66.4.147', fmt=raw size=104857600

# rbd ls libvirt-pool
haha.img
rbd1.img
rbd2.img
yy1.img
yy2.img

4. create haha.img in rbd pool with vol-create-as
# virsh vol-create-as rbd haha.img 100M
error: Failed to create vol haha.img
error: failed to create volume 'libvirt-pool/haha.img': Operation not permitted

5. haha.img disappared in libvirt-pool

# rbd ls libvirt-pool
rbd1.img
rbd2.img
yy1.img
yy2.img

Comment 3 John Ferlan 2015-06-23 20:30:04 UTC
I don't believe this is a bug. You're taking "knowledge" of how libvirt does something in order to "go behind libvirt's back" and create something. Then you decide to go back to using libvirt to manage the data in the pool.  Since you decided to use the same name, you now expect libvirt to manage that name.  That name failed (because of subterfuge), so libvirt handles the error by removing the volume that "a" it didn't know about originally and "b" caused some sort of issue.  Seems to me that's an "expected reaction" to a "unexpected condition".

Either you choose to have libvirt manage your storage or you choose not to. Going with some sort of hybrid model just cannot be "supported". Consider a 5G pool with 2G taken... You go and add a 3G volume outside of libvirt's knowledge, you don't refresh, and then attempt to use libvirt to create a 3G volume - it's going to fail, but libvirt won't know that until you refresh and libvirt "learns" about the existence of something it didn't know about or create and can adjust it's view of the space available in the pool.

Comment 4 Yang Yang 2015-06-29 06:46:15 UTC
(In reply to John Ferlan from comment #3)
> I don't believe this is a bug. You're taking "knowledge" of how libvirt does
> something in order to "go behind libvirt's back" and create something. Then
> you decide to go back to using libvirt to manage the data in the pool. 
> Since you decided to use the same name, you now expect libvirt to manage
> that name.  That name failed (because of subterfuge), so libvirt handles the
> error by removing the volume that "a" it didn't know about originally and
> "b" caused some sort of issue.  Seems to me that's an "expected reaction" to
> a "unexpected condition".

Um.. I think libvirt should avoid damaging existing available volume. How about doing a RefreshPool to get all logical volumes before CreateVol

> 
> Either you choose to have libvirt manage your storage or you choose not to.
> Going with some sort of hybrid model just cannot be "supported". Consider a
> 5G pool with 2G taken... You go and add a 3G volume outside of libvirt's
> knowledge, you don't refresh, and then attempt to use libvirt to create a 3G
> volume - it's going to fail, but libvirt won't know that until you refresh
> and libvirt "learns" about the existence of something it didn't know about
> or create and can adjust it's view of the space available in the pool.

Comment 5 John Ferlan 2015-07-13 11:19:02 UTC
I disagree still.  Expecting libvirt to do a refresh before a create in order to work around a self inflicted issue? It could just as easily be stated that if an admin attempts to manage storage outside of libvirt's knowledge, then that same admin should cause the refresh themselves in order to "teach" or "tell" libvirt what they did.

Now if libvirt had the ability to subscribe and process some sort of event from a file system or external storage server when adjustments were made "out of band" to the storage libvirt felt it was managing perhaps that might work, but that would require each of the storage targets that libvirt can manage to be able to generate the event and then libvirt to handle processing events for adjustment it recognizes or initiated versus those that were initiated by some action external to libvirt.

Comment 6 John Ferlan 2015-09-30 21:52:21 UTC
Even though I'm still of the opinion that modifying the pool contents outside libvirt borders on a "don't do that type operation", there is a check on the deleteVol side to determine that an unlink or rmdir failed because of ENOENT, then don't cause an error (e.g., don't cause an error if someone manipulated the pool outside libvirt's knowledge by removing the file/dir).

So I'll reopen and generate a patch for upstream shortly

Comment 7 John Ferlan 2015-10-02 13:45:51 UTC
Patch posted upstream:

http://www.redhat.com/archives/libvir-list/2015-October/msg00079.html

Comment 8 John Ferlan 2015-10-06 11:37:23 UTC
Pushed upstream as commit id 'fdda37608a6e22406fbdfe4ac0c573a96a8d0417'

git describe fdda37608a6e22406fbdfe4ac0c573a96a8d0417
v1.2.20-23-gfdda376

Comment 9 John Ferlan 2015-10-08 21:31:19 UTC
Ugh... Need to set back to assigned.... Commit will be reverted and other patches generated to handle this specific case and other more general cases.

Comment 10 John Ferlan 2015-10-13 23:06:31 UTC
More patches posted - patch 4 of the series fixes the specific problem, but extrapolating a bit to possible problems for other backends result in changes in patches 5-12, where patch 11 reverts the previous commit.

series start:
http://www.redhat.com/archives/libvir-list/2015-October/msg00312.html

patch 4:
http://www.redhat.com/archives/libvir-list/2015-October/msg00316.html

Comment 12 John Ferlan 2015-11-04 12:26:31 UTC
Reposted the patches, got reviews, made updates and pushed upstream

http://www.redhat.com/archives/libvir-list/2015-October/msg00810.html

updates from review from original series:

http://www.redhat.com/archives/libvir-list/2015-November/msg00093.html
http://www.redhat.com/archives/libvir-list/2015-November/msg00094.html

Pushed changes into upstream 1.2.22

commit 4cd7d220c9b93d559311c5c418c5aed0025763a2

$ git describe 4cd7d220c9b93d559311c5c418c5aed0025763a2
v1.2.21-13-g4cd7d22
$

Comment 13 John Ferlan 2015-11-16 12:10:08 UTC
*** Bug 1282283 has been marked as a duplicate of this bug. ***

Comment 15 yisun 2016-03-10 06:34:37 UTC
Verified on: libvirt-1.3.2-1.el7.x86_64
and PASSED

==== RBD storage ===
1. # virsh pool-dumpxml rbd
<pool type='rbd'>
  <name>rbd</name>
  <uuid>89733e5d-2883-43ed-8046-8005129da0d1</uuid>
  <capacity unit='bytes'>152820314112</capacity>
  <allocation unit='bytes'>1803247016</allocation>
  <available unit='bytes'>126306897920</available>
  <source>
    <host name='xxxxxxx' port='6789'/>
    <name>rbd</name>
  </source>
</pool>

2. # virsh vol-list rbd --details
 Name       Path           Type       Capacity  Allocation
-----------------------------------------------------------
 hhan.img   rbd/hhan.img   network    1.00 GiB    1.00 GiB
 V.qcow2    rbd/V.qcow2    network    3.00 GiB    3.00 GiB
 VVV.qcow2  rbd/VVV.qcow2  network      0.00 B      0.00 B
 ys1.img    rbd/ys1.img    network  100.00 MiB  100.00 MiB

3. # virsh vol-create-as rbd ys1.img 200M
error: Failed to create vol ys1.img
error: storage volume 'ys1.img' exists already

4. # virsh pool-refresh rbd; virsh vol-list rbd --details
Pool rbd refreshed

 Name       Path           Type       Capacity  Allocation
-----------------------------------------------------------
 hhan.img   rbd/hhan.img   network    1.00 GiB    1.00 GiB
 V.qcow2    rbd/V.qcow2    network    3.00 GiB    3.00 GiB
 VVV.qcow2  rbd/VVV.qcow2  network      0.00 B      0.00 B
 ys1.img    rbd/ys1.img    network  100.00 MiB  100.00 MiB


=========== iscsi ==============

1. # virsh pool-dumpxml iscsi
<pool type='iscsi'>
  <name>iscsi</name>
  <uuid>41c89778-5833-4a4e-809b-1d5831432c40</uuid>
  <capacity unit='bytes'>3221225472</capacity>
  <allocation unit='bytes'>3221225472</allocation>
  <available unit='bytes'>0</available>
  <source>
    <host name='xxxxxxxx'/>
    <device path='iqn.2014-12.com.redhat:libvirt-manual'/>
  </source>
  <target>
    <path>/dev/disk/by-path</path>
  </target>
</pool>


2. # virsh vol-list iscsi --details
 Name        Path                                                                                    Type   Capacity  Allocation
---------------------------------------------------------------------------------------------------------------------------------
 unit:0:0:1  /dev/disk/by-path/ip-10.66.5.88:3260-iscsi-iqn.2014-12.com.redhat:libvirt-manual-lun-1  block  1.00 GiB    1.00 GiB
 unit:0:0:2  /dev/disk/by-path/ip-10.66.5.88:3260-iscsi-iqn.2014-12.com.redhat:libvirt-manual-lun-2  block  1.00 GiB    1.00 GiB
 unit:0:0:3  /dev/disk/by-path/ip-10.66.5.88:3260-iscsi-iqn.2014-12.com.redhat:libvirt-manual-lun-3  block  1.00 GiB    1.00 GiB


3. # virsh vol-create-as iscsi unit:0:0:3 100M
error: Failed to create vol unit:0:0:3
error: storage volume 'unit:0:0:3' exists already


4. # virsh vol-list iscsi --details
 Name        Path                                                                                    Type   Capacity  Allocation
---------------------------------------------------------------------------------------------------------------------------------
 unit:0:0:1  /dev/disk/by-path/ip-10.66.5.88:3260-iscsi-iqn.2014-12.com.redhat:libvirt-manual-lun-1  block  1.00 GiB    1.00 GiB
 unit:0:0:2  /dev/disk/by-path/ip-10.66.5.88:3260-iscsi-iqn.2014-12.com.redhat:libvirt-manual-lun-2  block  1.00 GiB    1.00 GiB
 unit:0:0:3  /dev/disk/by-path/ip-10.66.5.88:3260-iscsi-iqn.2014-12.com.redhat:libvirt-manual-lun-3  block  1.00 GiB    1.00 GiB



====== dir ======
1. # virsh pool-dumpxml default
<pool type='dir'>
  <name>default</name>
  <uuid>80bf5440-5491-9247-043c-39eaa5962c13</uuid>
  <capacity unit='bytes'>42141450240</capacity>
  <allocation unit='bytes'>11058479104</allocation>
  <available unit='bytes'>31082971136</available>
  <source>
  </source>
  <target>
    <path>/var/lib/libvirt/images</path>
    <permissions>
      <mode>0711</mode>
      <owner>0</owner>
      <group>0</group>
      <label>system_u:object_r:virt_image_t:s0</label>
    </permissions>
  </target>
</pool>

2. # virsh vol-list default --details
 Name                         Path                                                 Type   Capacity  Allocation
---------------------------------------------------------------------------------------------------------------
 attacheddisk                 /var/lib/libvirt/images/attacheddisk                 file   1.00 GiB  196.00 KiB
 dir_pool                     /var/lib/libvirt/images/dir_pool                     dir      0.00 B      0.00 B
 dirpool                      /var/lib/libvirt/images/dirpool                      dir      0.00 B      0.00 B
 haha                         /var/lib/libvirt/images/haha                         file   1.00 MiB    1.00 MiB


3. # virsh vol-create-as default haha 100M
error: Failed to create vol haha
error: storage volume 'haha' exists already

4. # virsh vol-list default --details
 Name                         Path                                                 Type   Capacity  Allocation
---------------------------------------------------------------------------------------------------------------
 attacheddisk                 /var/lib/libvirt/images/attacheddisk                 file   1.00 GiB  196.00 KiB
 dir_pool                     /var/lib/libvirt/images/dir_pool                     dir      0.00 B      0.00 B
 dirpool                      /var/lib/libvirt/images/dirpool                      dir      0.00 B      0.00 B
 haha                         /var/lib/libvirt/images/haha                         file   1.00 MiB    1.00 MiB


========= lvm ===========
1. # virsh pool-dumpxml lvm
<pool type='logical'>
  <name>lvm</name>
  <uuid>12345678-1234-1234-1234-123456781234</uuid>
  <capacity unit='bytes'>1069547520</capacity>
  <allocation unit='bytes'>629145600</allocation>
  <available unit='bytes'>440401920</available>
  <source>
    <name>vg_libvirt</name>
    <format type='lvm2'/>
  </source>
  <target>
    <path>/dev/vg_libvirt</path>
  </target>
</pool>

2. # virsh vol-list lvm --details
 Name  Path                  Type     Capacity  Allocation
-----------------------------------------------------------
 haha  /dev/vg_libvirt/haha  block  100.00 MiB  100.00 MiB
 hehe  /dev/vg_libvirt/hehe  block  200.00 MiB  200.00 MiB
 hoho  /dev/vg_libvirt/hoho  block  300.00 MiB  300.00 MiB

3. # virsh vol-create-as lvm hoho 500M
error: Failed to create vol hoho
error: storage volume 'hoho' exists already

4. # virsh vol-list lvm --details
 Name  Path                  Type     Capacity  Allocation
-----------------------------------------------------------
 haha  /dev/vg_libvirt/haha  block  100.00 MiB  100.00 MiB
 hehe  /dev/vg_libvirt/hehe  block  200.00 MiB  200.00 MiB
 hoho  /dev/vg_libvirt/hoho  block  300.00 MiB  300.00 MiB

Comment 17 errata-xmlrpc 2016-11-03 18:18:57 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.

https://rhn.redhat.com/errata/RHSA-2016-2577.html


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