Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Co-existence, Ingestion and Upgrade cases


Test Case#

Category : Test Case Name

Test Case Description

Expected Result

Actual Result

1

Co-existence : New LPAR co-existence with Old LPAR

 

 

    • LPAR ‘old-lpar’
( Having active alone, passive alone?? And having both active and passive )
    • present in pre 4.0 and has some of volumes exported
    • Upgrade to 4.0
    • Add a new LPAR ‘new-lpar’ after upgrade as a virtual host
    • ( Add Volume ) Perform new volume export operations to new LPAR
    • ( Add Volume ) Perform new volume export operation to old LPAR
    • ( Remove Volume ) Perform un-export volume operation from 'old-lpar'
    • ( Remove Volume ) Perform un-export volume operation from 'new-lpar'
  • Export operation to “old-lpar’ and ‘new-lpar’ works without any issues
  • Un-export operation from 'old-lpar' and 'new-lpar' works without any issues.

 

2

Co-existence : Fake cluster and new LPAR

 

 

    • Fake cluster ‘fake-cluster’ having 2 LPARs one for active HBA and other for passive HBA is present in pre 4.0 and has some volumes exported.
    • Upgrade to 4.0
    • Add a new LPAR ‘new-lpar’ after upgrade as a virtual host to Fake cluster ‘fake-cluster’
    • ‘new-lpar’ should have both active and passive HBAs added
    • Perform volume export operations to ‘fake-cluster’
  • This falls in the category of invalid configuration and we don't expect user shall do such a configuration.

 

3

Co-existence : New LPAR co-existence with Old LPAR with any OS combinations

 

    • An existing LPAR and new LPAR must be able to co-exist with any other OS host  (regular AIX, Linux, HPUX, Solaris…) for a given Storage Array (VPLEX or VMAX initially, but also VNX, XIO, Unity, DellSC…)
    • LPAR ‘old-lpar’ present in pre4.0, this LPAR is with windows OS
    • Upgrade to 4.0
    • Add a new LPAR ‘new-lpar-aix’ as a virtual host
    • (Add Volume) Perform volume export operations to both lpars
    • (Remove Volume) perform volume un-export operation from both lpars

 

  • Export operations should go through with no issues.
  • Un-export operation works with no issues

 

4

Co-existence : New LPAR co-existence with ESX or Windows cluster

    • A new LPAR must be able to co-exist with any other cluster (ESX, Windows, regular AIX, Linux, HPUX, Solaris…) for a given Storage Array (VPLEX or VMAX initially, but also VNX, XIO, Unity, DellSC…)
    • A cluster exists in pre 4.0
    • Upgrade to 4.0
    • Add a new LPAR ‘new-lpar-aix’ as a virtual host
    • (Add Volume) Perform volume export operations to both lpars
    • (Remove Volume) perform volume un-export operation from both lpars
  • Export operation works with no issues
  • Un-export operation works with no issues

 

5

Upgrade : Old LPAR update

 

 

    • A host (Consider both manually added and discovered hosts) in ViPR (3.6) has some initiators and some volumes exported to it. After upgrading to Leia (or whatever release has the LPAR support), user tries to add a passive initiator to that host’s existing active initiator.

 

  • ViPR-C should reject this attempt to add a passive initiator since the host is not a virtual host.

 

 

6

Upgrade : Adding existing initiator WWN

    • A host is ViPR (3.6) has an initiator and some volumes exported to it. The admin tries to add a new LPAR but the active (or passive) virtual initiator has the same WWN as the existing host’s WWN.

 

  • ViPR-C should reject this attempt, since initiator already exists in ViPR DB.

 

7

Upgrade : LPAR with its VIO server

    • Admin adds an LPAR where the underlying VIO server is already part of ViPR DB, and some volumes are exported to it
  • ViPR-C should be able to support this – simultaneous export of volumes to LPAR and the physical server on which that LPAR is running

 

8

Upgrade : Active and passive belongs to different network??

    • Admin adds an LPAR where active initiator is part of one network, but the passive initiator belongs to another network
  • This is an invalid use case, we need to elaborate on why it is invalid case

 

9

Ingestion : Volumes exported to LPAR outside ViPR

    • LPAR has volumes exported before it is brought into ViPR, it has both active and passive initiators
    • Add this LPAR to ViPR
    • Ingest volumes exported to LPAR and bring them into ViPR

 

 

10

Ingestion : Volumes exported to LPAR cluster outside ViPR

    • Cluster of LPARs created and has volumes exported to it before it is brought into ViPR. All LPARs present in cluster have active and passive initiators
    • Add this cluster along with LPARs into ViPR
    • Ingest volumes exported to cluster, ingest volumes exported to individual hosts

 

 

11

Ingestion : SRDF protected volumes exported to LPAR host and LPAR cluster

    • LPAR cluster and or LPAR hosts have SRDF protected volumes exported
    • Add these cluster and host to ViPR
    • Ingest volumes exported to these cluster and host

 

 

12

Ingestion : Volumes with FAST policies exported to LPAR host and LPAR cluster

    • LPAR cluster and or LPAR hosts have FAST policy volumes exported
    • Add these cluster and host to ViPR
    • Ingest volumes exported to these cluster and host

 

 

13

Co-existence : Cluster with fake host and new LPAR

    • Cluster of LPARs is represented as a cluster with a host having active initiator and a fake host having passive initiator
    • Upgrade to 4.0
    • Add a new LPAR ‘new-lpar’ after upgrade as a virtual host to a cluster having fake host,
    • ‘new-lpar’ should have both active and passive HBAs added
    • Perform volume export operations to cluster

This falls in the category of invalid configuration

 

14Co-existence : VMAX : 1MV + Non-Cascaded SG + FAST 1
    • LPAR present in the data-center with one FAST volume already exported
    • ViPR gets deployed
    • Create LPAR as a virtual host in ViPR
    • Perform following operations
      • Create Export
      • Add Volume ( FAST policy )
      • Remove volume
      • Add Initiator
      • Remove Initiator


Create Export : MV reused and a new export mask gets created in ViPR and volumes are added to it.

Add Volume : The volume gets added to non-cascaded SG in MV1

Remove Volume : Volume will be removed, but MV remains on the storage system as it is not created by ViPR. If external volumes are removed by the user and the volume to be removed from ViPR is the last volume, then such MV will be deleted.

Add Initiator : Initiator gets added to the IG in the MV1

Remove Initiator : Initiator gets removed from ViPR mask, but it will not be removed from the IG on the array.



15Ingestion : VMAX : 1MV + Non-Cascaded SG + FAST 1
  • LPAR present in the data-center with one FAST volume already exported
  • ViPR gets deployed
  • Create LPAR as a virtual host in ViPR
  • Ingest the volume already exported into ViPR
  • Perform following operations
    • Add Volume ( FAST policy )
    • Remove volume
    • Add Initiator
    • Remove Initiator

Add Volume : The volume gets added to non-cascaded SG in MV1

Remove Volume : Volume removed, and if its the last Volume, then MV1 will be deleted.

Add Initiator : Initiator gets added to the IG in the MV1

Remove Initiator : Initiator removed from IG. MV1 will be deleted if this is the last initiator to be removed.


16Co-existence : VMAX :

2 Masking Views

MV 1 + Non-Cascaded SG + FAST 1

MV 2 + Non-Cascaded SG + FAST 2

  • LPAR present in the data-center with one FAST volume already exported
  • ViPR gets deployed
  • Create LPAR as a virtual host in ViPR
  • Perform following operations
    • Create Export
    • Add Volume ( FAST policy )
    • Remove volume
    • Add Initiator
    • Remove Initiator

Create Export (FAST1) : MVs reused, 2 Export Masks created in ViPR, and volume gets to added to the masking views based on FAST policy selected, in this case MV 1 is selected.

Add Volume ( FAST1 ) : The volume gets added to non-cascaded SG in MV1

Remove Volume : Volume gets removed from the right MV. MV will be removed if it is the last volume to be removed from MV

Add Initiator : Initiator Added to IG , as IG is shared across these masking views, the initiator indirectly gets added to both MVs.

Remove Initiator : Initiator gets removed from ViPR mask, but it will not be removed from the IG on the array.


17Ingestion : VMAX :

2 Masking Views

MV 1 + Non-Cascaded SG + FAST 1

MV 2 + Non-Cascaded SG + FAST 2

  • LPAR present in the data-center with one FAST volume already exported
  • ViPR gets deployed
  • Create LPAR as a virtual host in ViPR
  • Ingest the volume already exported into ViPR
  • Perform following operations
    • Add Volume ( FAST policy )
    • Remove volume
    • Add Initiator
    • Remove Initiator

Add Volume ( FAST1 ) : The volume gets added to non-cascaded SG in MV1

Remove Volume : Volume gets removed from the right MV. MV will be removed if it is the last volume to be removed from MV

Add Initiator : Initiator Added to IG , as IG is shared across these masking views, the initiator indirectly gets added to both MVs.

Remove Initiator : Initiator gets removed from ViPR mask, if it is the last initiator to be removed, then IG gets deleted and so the MV.



Exclusions and Limitations

...