Previously removed iSCSI multipath volumes can be rediscovered by future disconnect_volume calls before being unmapped on the backend by os-terminate_connection.
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: