Bug 1304319 - Manually created cow clone of rbd device is removed by virStorageBackendRBDBuildVolFrom if it has the same name as existing one
Summary: Manually created cow clone of rbd device is removed by virStorageBackendRBDBu...
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-03 10:05 UTC by Yang Yang
Modified: 2024-12-17 12:04 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2024-12-17 12:04:18 UTC
Embargoed:


Attachments (Terms of Use)

Description Yang Yang 2016-02-03 10:05:56 UTC
Description of problem:
If I manually create a cow clone of rbd device using 'rbd clone xxx', later if I create a rbd volume which has the same name as that I created before using 'virsh vol-clone xxx'. Then the manually created image is removed


Version-Release number of selected component (if applicable):
libvirt-1.3.2-1.fc24_v1.3.1_79_g63e15ad.x86_64

How reproducible:
100%

Steps to Reproduce:
1. create a rbd pool 
# cat rbd.xml 
<pool type='rbd'>
  <name>rbd</name>
  <source>
    <host name='10.73.68.116'/>
    <host name='10.73.68.117'/>
    <host name='10.73.68.118'/>
    <name>yy</name>
  </source>
</pool>

# virsh vol-list rbd
 Name                 Path                                    
------------------------------------------------------------------------------
 vol1                 yy/vol1                                 
 vol1.clone1          yy/vol1.clone1                          
 vol1.clone2          yy/vol1.clone2                          
 vol1.clone3          yy/vol1.clone3                          
 vol1.clone4          yy/vol1.clone4

2. create a cow clone using 'rbd clone xxx'
# rbd clone yy/vol1@sn1 yy/vol1.clone5
[root@fedora_yy ~]# rbd ls yy
vol1
vol1.clone1
vol1.clone2
vol1.clone3
vol1.clone4
vol1.clone5
                        
3. create vol1.clone5 using vol-clone
[root@fedora_yy ~]# virsh vol-clone vol1 vol1.clone5 rbd
error: Failed to clone vol from vol1
error: failed to clone RBD volume vol1 to vol1.clone5: File exists

4. check if vol1.clone5 exists
[root@fedora_yy ~]# rbd ls yy
vol1
vol1.clone1
vol1.clone2
vol1.clone3
vol1.clone4

Actual results:
Manually created cow clone is removed

Expected results:
Manually created cow clone should not be removed


Additional info:

Comment 1 Wido den Hollander 2016-02-09 12:00:38 UTC
I think this is because libvirt thinks the cloning operation failed and it tries to clean up.

If you would refresh the pool after creating the RBD volume manually this wouldn' t happen.

This is more a libvirt logic problem then a RBD storage driver specific issue.

Good catch though, but I don't know how to fix this right now.

Comment 2 John Ferlan 2016-02-09 12:49:25 UTC
oh... ouch... Long story short, I fixed a similar issue in/from the buildVol path; however, I seem to have forgotten the buildVolFrom path mainly because there was no rbd buildVolFrom code at the time.  The two existing buildVolFrom backend API's in FS and DISK used code which ended up down in the path of buildVol, so it slipped my mind.

Anyway, see commit id '4cd7d220c9b' - there's a lot of patches that support that and quite a bit of history, but I believe if you make a similar change in storageVolCreateXMLFrom where if "buildret < 0" rather than calling DeleteInternal, call storageVolRemoveFromPool using newvol

Also helps that you can "test" my theory with a real rbd instance!

Comment 3 Daniel Berrangé 2024-12-17 12:04:18 UTC
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.


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