Bug 1158091 - RFE: storage: Add supporting gluster/iscsi as backing file when create a volume
Summary: RFE: storage: Add supporting gluster/iscsi as backing file when create a volume
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-28 14:43 UTC by Shanzhi Yu
Modified: 2020-11-03 16:59 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-03 16:59:55 UTC
Embargoed:


Attachments (Terms of Use)

Description Shanzhi Yu 2014-10-28 14:43:36 UTC
Description of problem:

Add supporting gluster/iscsi as backing file when create a volume 

Version-Release number of selected component (if applicable):

libvirt-1.2.8-5.el7.x86_64

How reproducible:

100%

Steps to Reproduce:

1. Prepare dir pool name default
# virsh pool-list
Name State Autostart
-------------------------------------------
default active yes

2. Prepare a volume xml file
# cat vol.xml
<volume type='file'>
<name>vol.img</name>
<key>/var/lib/libvirt/images/vol.img</key>
<source>
</source>
<capacity unit='bytes'>1073741824</capacity>
<allocation unit='bytes'>200704</allocation>
<target>
<path>/var/lib/libvirt/images/vol.img</path>
<format type='qcow2'/>
<compat>1.1</compat>
<features/>
</target>
<backingStore>
<path>gluster://10.66.6.111/gluster-vol1/rhel65.img</path>
<format type='raw'/>
</backingStore>
</volume>

3. Create volume

# virsh vol-create default vol.xml
error: Failed to create vol from vol.xml
error: inaccessible backing store volume gluster://10.66.6.111/gluster-vol1/rhel65.img: No such file or directory




Actual results:

Failed in step 3

Expected results:

Succeed creating volume with gluster backend as backing file

Additional info: 

same story with iscsi backend

# virsh vol-create default vol.xml
error: Failed to create vol from vol.xml
error: inaccessible backing store volume
iscsi://10.66.100.101/iqn.yy:server.target1/1: No such file or directory

# qemu-img info iscsi://10.66.100.101/iqn.yy:server.target1/1
image: iscsi://10.66.100.101/iqn.yy:server.target1/1
file format: raw
virtual size: 8.0G (8591507456 bytes)
disk size: unavailable

Comment 1 Shanzhi Yu 2014-10-28 14:46:11 UTC
Please ignore the Version-Release libvirt-1.2.8-5.el7.x86_64 as this can reproduce on fedora20 with latest libvirt

Comment 5 Fedora End Of Life 2015-05-29 13:10:44 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 6 Cole Robinson 2016-04-10 19:47:24 UTC
Probably still relevant. I suspect a major problem is that the storage APIs expect backing files to be within the parent pool, and just uses one set of backend APIs for storage creation. There probably needs to be some cross backend awareness

Comment 8 Daniel Berrangé 2020-11-03 16:59:55 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.