Red Hat Bugzilla – Bug 1472277
An attempt to start a vHBA storage pool backed by an already pre-created vHBA returns unknown cause error
Last modified: 2017-09-05 05:35:46 EDT
Description of problem:
When trying to start a storage pool where the underlying vHBA device already exists, libvirt returns an unknown cause error.
Version-Release number of selected component (if applicable):
libvirt-3.2.0 and onward
Steps to Reproduce:
1. pre-create a vHBA device via nodedev driver (XML example below)
2. define a scsi storage pool
# virsh pool-dumpxml npiv
<adapter type='fc_host' parent='scsi_host8' managed='no' wwnn='20000000c99e2b81' wwpn='1000000000000001'/>
3. start the pool
# virsh pool-start npiv
error: Failed to start pool npiv
error: An error occurred, but the cause is unknown
The pool is started successfully.
hrmph... various refactors in the code broke this check.
I've posted a patch to resolve:
as part of a series
Review of original changes, results in following patch:
as part of a v3 of series:
which now has been pushed:
$ git describe c4030331c8bd820c6825db2dcd23c8743a5b9297
$ git show c4030331c8bd820c6825db2dcd23c8743a5b9297
Author: John Ferlan <firstname.lastname@example.org>
Date: Tue Jul 18 09:21:30 2017 -0400
storage: Fix existing parent check for vHBA creation
Commit id '106930aaa' altered the order of checking for an existing
vHBA (e.g something created via nodedev-create functionality outside
of the storage pool logic) which inadvertantly broke the code to
decide whether to alter/force the fchost->managed field to be 'yes'
because the storage pool will be managing the created vHBA in order
to ensure when the storage pool is destroyed that the vHBA is also
This patch moves the check (and checkParent helper) for an existing
vHBA back into the createVport in storage_backend_scsi. It also
adjusts the checkParent logic to more closely follow the intentions
prior to commit id '79ab0935'. The changes made by commit id '08c0ea16f'
are only necessary to run the virStoragePoolFCRefreshThread when
a vHBA was really created because there's a timing lag such that
the refreshPool call made after a startPool from storagePoolCreate*
wouldn't necessarily find LUNs, but the thread would. For an already
existing vHBA, using the thread is unnecessary since the vHBA already
exists and the lag to configure the LUNs wouldn't exist.
Signed-off-by: John Ferlan <email@example.com>