Description of problem: Unknown error out when rbd volume create/build fails with enabled authentication Version-Release number of selected component (if applicable): libvirt-1.2.17-2.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1. define/start a rbd pool with authentication enabled # virsh pool-dumpxml rbd <pool type='rbd'> <name>rbd</name> <uuid>89733e5d-2883-43ed-8046-8005129da0d1</uuid> <capacity unit='bytes'>0</capacity> <allocation unit='bytes'>0</allocation> <available unit='bytes'>0</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> <auth type='ceph' username='libvirt'> <secret usage='client.libvirt secret'/> </auth> </source> </pool> 2. create a vol with flag prealloc-metadata # virsh vol-create-as rbd yy3.img 100M --format raw --prealloc-metadata error: Failed to create vol yy3.img error: An error occurred, but the cause is unknown 3. Actual results: unknown error out Expected results: It should report error like this error: Failed to create vol yy3.img error: unsupported flags (0x1) in function virStorageBackendRBDBuildVol Additional info:
The offending call to storageVolDeleteInternal which in turn called a secret lookup API was removed by: commit 4cd7d220c9b93d559311c5c418c5aed0025763a2 Author: John Ferlan <jferlan> CommitDate: 2015-11-04 07:21:11 -0500 storage: On 'buildVol' failure don't delete the volume https://bugzilla.redhat.com/show_bug.cgi?id=1233003 Commit id 'fdda3760' only managed a symptom where it was possible to create a file in a pool without libvirt's knowledge, so it was reverted. The real fix is to have all the createVol API's which actually create a volume (disk, logical, zfs) and the buildVol API's which handle the real creation of some volume file (fs, rbd, sheepdog) manage deleting any volume which they create when there is some sort of error in processing the volume. This way the onus isn't left up to the storage_driver to determine whether the buildVol failure was due to some failure as a result of adjustments made to the volume after creation such as getting sizes, changing ownership, changing volume protections, etc. or simple a failure in creation. Without needing to consider that the volume has to be removed, the buildVol failure path only needs to remove the volume from the pool. This way if a creation failed due to duplicate name, libvirt wouldn't remove a volume that it didn't create in the pool target. git describe: v1.2.21-13-g4cd7d220c9 contains: v1.3.0-rc1~190