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
Please ignore the Version-Release libvirt-1.2.8-5.el7.x86_64 as this can reproduce on fedora20 with latest libvirt
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.
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
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.