[libvirt] [PATCH v2 0/5] Resolve fc_host startup, shutdown issues

[Michal Privoznik]

On 10.11.2014 23:45, John Ferlan wrote:
> This series will replace:
>
> http://www.redhat.com/archives/libvir-list/2014-November/msg00197.html
>
> There are two bugs being fixed here and having them reviewed together
> makes things easier in the long run as the last 3 patches depended upon
> the first 2 being present.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1160565
>
> Patch 1 is as was in the previous set
> Patch 2 is essentially the same, except the single function
>          checkVhbaSCSIHostParent was split out to generate a
>          getVhbaSCSIHostParent which gets used later on.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1160926
>
> Patch 3 fixes an issue which took a bit of gdb time in order
>          to figure out exactly what was going wrong. Essentially,
>          the exising createVport code had a path which would find
>          the "best available" fc_host to use and save the parent on
>          return so that the deleteVport code would delete the parent.
>          However, the code used a copy of the adapter not a reference
>          to the adapter and thus the change was lost leaving the vHBA
>          on the system.
>
> Patch 4 adds a new function to save the StoragePool XML given a
>          configFile. This will be used in the next patch because
>          while having the in memory fchost copy updated does work -
>          if libvirtd dies in between we're back at square 1 reading
>          storage pool config files and not knowing whence we started.
>
> Patch 5 adds a new "managed" attribute to the fchost XML. It does this
>          mainly to let the deleteVport know when it should delete the
>          self created vport.  Prior to this code, the reliance was that
>          we didn't have a parent provided. However, this causes an issue
>          where if someone used nodedev-create in order to create a vHBA
>          and then tried to use that vHBA in a storage pool we would delete
>          that vHBA when we were done, which may not be expected. Using
>          the managed attribute at creation time will let libvirt know
>          what to do in this case.
>
> NOTE: There's still one more issue in the code, but it's a bit trickier
> to resolve. A libvirt created vport doesn't seem to want to find the LUN's
> on the initial PoolRefresh that occurs during startup. However, if one
> does a refresh immediately after starting the pool, the luns show up.
> It seems perhaps there's some sort of locking issue that won't allow the
> udevEventHandleCallback to 'add' the new device.
>
> John Ferlan (5):
>    storage: Check for valid fc_host parent at startup
>    storage: Ensure fc_host parent matches wwnn/wwpn
>    storage: Don't use a stack copy of the adapter
>    storage: Introduce virStoragePoolSaveConfig
>    storage: Introduce 'managed' for the fchost parent
>
>   docs/formatstorage.html.in                         |  28 ++-
>   docs/schemas/basictypes.rng                        |   5 +
>   src/conf/storage_conf.c                            |  70 ++++--
>   src/conf/storage_conf.h                            |   4 +
>   src/libvirt_private.syms                           |   1 +
>   src/storage/storage_backend_scsi.c                 | 237 ++++++++++++++++++---
>   .../pool-scsi-type-fc-host-managed.xml             |  15 ++
>   .../pool-scsi-type-fc-host-managed.xml             |  18 ++
>   tests/storagepoolxml2xmltest.c                     |   1 +
>   9 files changed, 323 insertions(+), 56 deletions(-)
>   create mode 100644 tests/storagepoolxml2xmlin/pool-scsi-type-fc-host-managed.xml
>   create mode 100644 tests/storagepoolxml2xmlout/pool-scsi-type-fc-host-managed.xml
>

ACK series

Michal