Description of problem: Previously removed iSCSI multipath volumes can be rediscovered by future disconnect_volume calls before being unmapped on the backend by os-terminate_connection. This becomes a real issue when the mutlipath configuration for a given backend defaults to using queue_if_no_path as rediscovered devices will queue I/O once they have been unmapped. Version-Release number of selected component (if applicable): N/A How reproducible: Unclear at present. RHBZ#1351169 documents an example using a VNX backend but further attempts to reproduce this with a basic iSCSI/LVM environment have been inconclusive. Steps to Reproduce: 1. Boot multiple volume backed instances using a multipath iSCSI backend. Ensure queue_if_no_path is configured for the environment. 2. Delete instances, forcing multiple disconnect_volume calls to be made to a single host. Actual results: Multipath devices are not removed with their path devices marked as faulty. systemd-udev processes can also be seen in a D state on the host in question. Expected results: Multipath devices and their underlying path devices are removed correctly from the host during disconnect_volume and are not rediscovered. Additional info:
Closed without a fix therefore QE won't automate