[libvirt] [PATCH 2/2] storage: Add thread to refresh for createVport

[Michal Privoznik]

On 19.11.2014 21:52, John Ferlan wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1152382
>
> When libvirt create's the vport (VPORT_CREATE) for the vHBA, there isn't
> enough "time" between the creation and the running of the following
> backend->refreshPool after a backend->startPool in order to find the LU's.
> Population of LU's happens asynchronously when udevEventHandleCallback
> discovers the "new" vHBA port.  Creation of the infrastructure by udev
> is an iterative process creating and discovering actual storage devices and
> adjusting the environment.
>
> Because of the time it takes to discover and set things up, the backend
> refreshPool call done after the startPool call will generally fail to
> find any devices. This leaves the newly started pool appear empty when
> querying via 'vol-list' after startup. The "workaround" has always been
> to run pool-refresh after startup (or any time thereafter) in order to
> find the LU's. Depending on how quickly run after startup, this too may
> not find any LUs in the pool. Eventually though given enough time and
> retries it will find something if LU's exist for the vHBA.
>
> This patch adds a thread to be executed after the VPORT_CREATE which will
> attempt to find the LU's without requiring the external run of refresh-pool.
> It does this by waiting for 5 seconds and searching for the LU's. If any
> are found, then the thread completes; otherwise, it will retry once more
> in another 5 seconds.  If none are found in that second pass, the thread
> gives up.
>
> Things learned while investigating this... No need to try and fill the
> pool too quickly or too many times. Over the course of creation, the udev
> code may 'add', 'change', and 'delete' the same device. So if the refresh
> code runs and finds something, it may display it only to have a subsequent
> refresh appear to "lose" the device. The udev processing doesn't seem to
> have a way to indicate that it's all done with the creation processing of a
> newly found vHBA. Only the Lone Ranger has silver bullets to fix everything.
>
> Signed-off-by: John Ferlan <jferlan at redhat.com>
> ---
>   src/storage/storage_backend_scsi.c | 131 +++++++++++++++++++++++++++++++++----
>   1 file changed, 120 insertions(+), 11 deletions(-)

ACK

Michal