Patch 1 just makes sure that prior to calling refreshPool we make sure to clear the objects; otherwise, the refresh code will duplicate. Text within patch 3 seems to indicate that entries were showing up more than once - although those may be bug related. In any case, although perhaps not necessary here - better safe than sorry. Patch 2 is a rework of changes that went into 1.3.2 related to how libvirt_parthelper generates the volume target path name that didn't quite get the algorithm right when the device source path ended with a non numeric value. As it turns out it seems the naming algorithm is much "simpler"; however, rather than just remove the attribute, I figured it should be kept "just in case" something *needed* to add that "p" it would be possible. It seems from output described here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/DM_Multipath/dmsetup_queries.html That it would be possible. Patch 3 was probably seen because Patch 2 testing occurs, so the same "sequence" used in other disk backend based testing was attempted. As it turns out, I don't believe the deletion for a multipath device ever really worked. The original patch could have been reverted except that it intermingled changes to support linking device-mapper with parthelper. John Ferlan (3): storage: Need to clear pool prior to calling the refreshPool storage: Fix algorithm generating path names for devmapper storage: Fix virStorageBackendDiskDeleteVol for device mapper configure.ac | 15 ++---- docs/formatstorage.html.in | 18 ++----- src/storage/parthelper.c | 13 +++-- src/storage/storage_backend_disk.c | 108 ++++++++++++++++++++++++------------- src/storage/storage_driver.c | 3 ++ 5 files changed, 89 insertions(+), 68 deletions(-) -- 2.5.5 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list