[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

On 10.11.2014 23:45, John Ferlan wrote:
This series will replace:


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.


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.


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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]