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

[John Ferlan]

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

-- 
1.9.3