All,

A question related to the setup of a new IASP under PowerHA/Metro mirror.

I have defined my IASP on the source node, but the metro mirror & powerHA setup still needs to be done.

Regarding the 'target' luns (of the metro mirror relationship) on the backup PT node, it is still recommended  or required (?) to init/format these luns first on the Backup node (only init & format), and afterwards continue with the metro mirror & powerHA setup.

Or should I consider this action as an additional validation of my storage assignments ? 

Thanks,

Kind regards,

Jos (Jozef) Thijs

Jozef,

You don't need/ you should not format the target disks on the target node. 

The proper sequence is: 

1. Create the iASP and add disks on the source node (this operation will format all LUNs but just on source node). 
2. Enable the replication between source and target.   

The replication process will copy all "0" and "1" to the DR disks, you don't need to worry about formatting. Obviously, initiating of the replication will hardly affect storage performance in both locations. 

All,

A question related to the setup of a new IASP under PowerHA/Metro mirror.

I have defined my IASP on the source node, but the metro mirror & powerHA setup still needs to be done.

Regarding the 'target' luns (of the metro mirror relationship) on the backup PT node, it is still recommended  or required (?) to init/format these luns first on the Backup node (only init & format), and afterwards continue with the metro mirror & powerHA setup.

Or should I consider this action as an additional validation of my storage assignments ? 

Thanks,

Kind regards,

Jos (Jozef) Thijs

Thanks Bartlomiej,

Yes, I had the same idea as your feedback, but in some IBM redbooks I found these sections:

In the redbook - PowerHA System Mirror for IBMi Cookbook / SG24-7994 - Jan 2012): 

Initializing IBM i disk units on the backup nodes Prior to setting up Copy Services on SVC/V7000

You have to initialize and format the read-protected DPHxxx disk units to become usable for the IASP on the IBM i backup nodes. This can be done in SST by choosing option 3 (Working with disk units), then selecting option 3 (Work with disk unit recovery), then selecting option 2 (Disk unit problem recovery procedure), and finally selecting option 1 (Initialize and format disk unit).

Failing to do so can result in IASP disk units not showing up properly after a switchover/failover to the secondary system

And a similar section was found in the Redpaper REDP4923 (2013)

And in fact, a similar question about the FlashCopy target luns of an IASP ... should these luns be initialized on the target FC partition (before arranging a FC) to assure the IASP can be activated.

Jozef,

You don't need/ you should not format the target disks on the target node. 

The proper sequence is: 

1. Create the iASP and add disks on the source node (this operation will format all LUNs but just on source node). 
2. Enable the replication between source and target.   

The replication process will copy all "0" and "1" to the DR disks, you don't need to worry about formatting. Obviously, initiating of the replication will hardly affect storage performance in both locations. 

All,

A question related to the setup of a new IASP under PowerHA/Metro mirror.

I have defined my IASP on the source node, but the metro mirror & powerHA setup still needs to be done.

Regarding the 'target' luns (of the metro mirror relationship) on the backup PT node, it is still recommended  or required (?) to init/format these luns first on the Backup node (only init & format), and afterwards continue with the metro mirror & powerHA setup.

Or should I consider this action as an additional validation of my storage assignments ? 

Thanks,

Kind regards,

Jos (Jozef) Thijs

Hmm, there are talking about just formatting disks. So, maybe it was an idea behind is to clear the disks which potentially were used for some other system before. 

I've never formatted the disks and has never issue with the iASP. But, I always had "new" LUNs from an external storage. 

Thanks Bartlomiej,

Yes, I had the same idea as your feedback, but in some IBM redbooks I found these sections:

In the redbook - PowerHA System Mirror for IBMi Cookbook / SG24-7994 - Jan 2012): 

Initializing IBM i disk units on the backup nodes Prior to setting up Copy Services on SVC/V7000

You have to initialize and format the read-protected DPHxxx disk units to become usable for the IASP on the IBM i backup nodes. This can be done in SST by choosing option 3 (Working with disk units), then selecting option 3 (Work with disk unit recovery), then selecting option 2 (Disk unit problem recovery procedure), and finally selecting option 1 (Initialize and format disk unit).

Failing to do so can result in IASP disk units not showing up properly after a switchover/failover to the secondary system

And a similar section was found in the Redpaper REDP4923 (2013)

And in fact, a similar question about the FlashCopy target luns of an IASP ... should these luns be initialized on the target FC partition (before arranging a FC) to assure the IASP can be activated.

Jozef,

You don't need/ you should not format the target disks on the target node. 

The proper sequence is: 

1. Create the iASP and add disks on the source node (this operation will format all LUNs but just on source node). 
2. Enable the replication between source and target.   

The replication process will copy all "0" and "1" to the DR disks, you don't need to worry about formatting. Obviously, initiating of the replication will hardly affect storage performance in both locations. 

All,

A question related to the setup of a new IASP under PowerHA/Metro mirror.

I have defined my IASP on the source node, but the metro mirror & powerHA setup still needs to be done.

Regarding the 'target' luns (of the metro mirror relationship) on the backup PT node, it is still recommended  or required (?) to init/format these luns first on the Backup node (only init & format), and afterwards continue with the metro mirror & powerHA setup.

Or should I consider this action as an additional validation of my storage assignments ? 

Thanks,

Kind regards,

Jos (Jozef) Thijs

This is a good question and Bart is correct that initializing and formatting disk units is no longer required as of more recent PTF levels.

At the time when those redbooks and redpapers were written, if you didn't first attach the target volumes and initialize and format them (with spectrum virtualize based storage such as IBM FlashSystem) they were on the target system as DPH units. This would cause the first switch to have the units fail to report in without resetting the virtual IOP or performing an IPL. 

With more current PTFs, this requirement was changed as the system will now process even those DPH units as part of a switch. You can see this reflected as well on the following page about adding units where it does not have you initialize and format on the backup system: https://helpsystemswiki.atlassian.net/wiki/spaces/IWT/pages/978223109/Adding+Disk+Units+in+an+SVC+Environment

You can similarly see on the more recent documentation for configuring asynchronous policy based replication with PowerHA that there are no steps for initializing and formatting disk units on the target system: https://helpsystemswiki.atlassian.net/wiki/spaces/IWT/pages/2990833680/Configuring+PowerHA+with+SVC+Asynchronous+Policy-based+Replication+7.5

Volumes from DS000 never had this behavior or requirement. 

Hmm, there are talking about just formatting disks. So, maybe it was an idea behind is to clear the disks which potentially were used for some other system before. 

I've never formatted the disks and has never issue with the iASP. But, I always had "new" LUNs from an external storage. 

Thanks Bartlomiej,

Yes, I had the same idea as your feedback, but in some IBM redbooks I found these sections:

In the redbook - PowerHA System Mirror for IBMi Cookbook / SG24-7994 - Jan 2012): 

Initializing IBM i disk units on the backup nodes Prior to setting up Copy Services on SVC/V7000

You have to initialize and format the read-protected DPHxxx disk units to become usable for the IASP on the IBM i backup nodes. This can be done in SST by choosing option 3 (Working with disk units), then selecting option 3 (Work with disk unit recovery), then selecting option 2 (Disk unit problem recovery procedure), and finally selecting option 1 (Initialize and format disk unit).

Failing to do so can result in IASP disk units not showing up properly after a switchover/failover to the secondary system

And a similar section was found in the Redpaper REDP4923 (2013)

And in fact, a similar question about the FlashCopy target luns of an IASP ... should these luns be initialized on the target FC partition (before arranging a FC) to assure the IASP can be activated.

Jozef,

You don't need/ you should not format the target disks on the target node. 

The proper sequence is: 

1. Create the iASP and add disks on the source node (this operation will format all LUNs but just on source node). 
2. Enable the replication between source and target.   

The replication process will copy all "0" and "1" to the DR disks, you don't need to worry about formatting. Obviously, initiating of the replication will hardly affect storage performance in both locations. 

All,

A question related to the setup of a new IASP under PowerHA/Metro mirror.

I have defined my IASP on the source node, but the metro mirror & powerHA setup still needs to be done.

Regarding the 'target' luns (of the metro mirror relationship) on the backup PT node, it is still recommended  or required (?) to init/format these luns first on the Backup node (only init & format), and afterwards continue with the metro mirror & powerHA setup.

Or should I consider this action as an additional validation of my storage assignments ? 

Thanks,

Kind regards,

Jos (Jozef) Thijs

Bart, Brian, 

Thanks very much for your feedback.

Sorry, another question ... in the context of iasps.

In case of a full system restore operation (sysbase & iasp) on another server (migrating to new Power and new storage server)), I have to use the CFGDEVASP command (defined within my BRMS recovery report) only on the lpar, which functions as the source server within my PowerHA configuration. And afterwards, I can vary-on the iasp device, and continue with the restore operations of all libraries / dir in sysbase & iasp. 

On my new Target server (and new Flashcopy server), I don't have to use this CFGDEVASP command. Of course, I have to restore the sysbase completely, and I have to assure that the powerHA configuration (CRGs, ASP Copy descriptions) is well updated with the new storage server ip-address, and the new volumes.  And afterwards, starting my SVC session to startup the metro mirror ( or FC operation). Is my view here right ?

Afterwards, I change from primary site without any additional requirement ?

Thanks in advance for your feedback,

Kind regards,

Jos

This is a good question and Bart is correct that initializing and formatting disk units is no longer required as of more recent PTF levels.

At the time when those redbooks and redpapers were written, if you didn't first attach the target volumes and initialize and format them (with spectrum virtualize based storage such as IBM FlashSystem) they were on the target system as DPH units. This would cause the first switch to have the units fail to report in without resetting the virtual IOP or performing an IPL. 

With more current PTFs, this requirement was changed as the system will now process even those DPH units as part of a switch. You can see this reflected as well on the following page about adding units where it does not have you initialize and format on the backup system: https://helpsystemswiki.atlassian.net/wiki/spaces/IWT/pages/978223109/Adding+Disk+Units+in+an+SVC+Environment

You can similarly see on the more recent documentation for configuring asynchronous policy based replication with PowerHA that there are no steps for initializing and formatting disk units on the target system: https://helpsystemswiki.atlassian.net/wiki/spaces/IWT/pages/2990833680/Configuring+PowerHA+with+SVC+Asynchronous+Policy-based+Replication+7.5

Volumes from DS000 never had this behavior or requirement. 

Hmm, there are talking about just formatting disks. So, maybe it was an idea behind is to clear the disks which potentially were used for some other system before. 

I've never formatted the disks and has never issue with the iASP. But, I always had "new" LUNs from an external storage. 

Thanks Bartlomiej,

Yes, I had the same idea as your feedback, but in some IBM redbooks I found these sections:

In the redbook - PowerHA System Mirror for IBMi Cookbook / SG24-7994 - Jan 2012): 

Initializing IBM i disk units on the backup nodes Prior to setting up Copy Services on SVC/V7000

You have to initialize and format the read-protected DPHxxx disk units to become usable for the IASP on the IBM i backup nodes. This can be done in SST by choosing option 3 (Working with disk units), then selecting option 3 (Work with disk unit recovery), then selecting option 2 (Disk unit problem recovery procedure), and finally selecting option 1 (Initialize and format disk unit).

Failing to do so can result in IASP disk units not showing up properly after a switchover/failover to the secondary system

And a similar section was found in the Redpaper REDP4923 (2013)

And in fact, a similar question about the FlashCopy target luns of an IASP ... should these luns be initialized on the target FC partition (before arranging a FC) to assure the IASP can be activated.

Jozef,

You don't need/ you should not format the target disks on the target node. 

The proper sequence is: 

1. Create the iASP and add disks on the source node (this operation will format all LUNs but just on source node). 
2. Enable the replication between source and target.   

The replication process will copy all "0" and "1" to the DR disks, you don't need to worry about formatting. Obviously, initiating of the replication will hardly affect storage performance in both locations. 

All,

A question related to the setup of a new IASP under PowerHA/Metro mirror.

I have defined my IASP on the source node, but the metro mirror & powerHA setup still needs to be done.

Regarding the 'target' luns (of the metro mirror relationship) on the backup PT node, it is still recommended  or required (?) to init/format these luns first on the Backup node (only init & format), and afterwards continue with the metro mirror & powerHA setup.

Or should I consider this action as an additional validation of my storage assignments ? 

Thanks,

Kind regards,

Jos (Jozef) Thijs

Bart, Brian, 

Thanks very much for your feedback.

Sorry, another question ... in the context of iasps.

In case of a full system restore operation (sysbase & iasp) on another server (migrating to new Power and new storage server)), I have to use the CFGDEVASP command (defined within my BRMS recovery report) only on the lpar, which functions as the source server within my PowerHA configuration. And afterwards, I can vary-on the iasp device, and continue with the restore operations of all libraries / dir in sysbase & iasp. 

On my new Target server (and new Flashcopy server), I don't have to use this CFGDEVASP command. Of course, I have to restore the sysbase completely, and I have to assure that the powerHA configuration (CRGs, ASP Copy descriptions) is well updated with the new storage server ip-address, and the new volumes.  And afterwards, starting my SVC session to startup the metro mirror ( or FC operation). Is my view here right ?

Afterwards, I change from primary site without any additional requirement ?

Thanks in advance for your feedback,

Kind regards,

Jos

This is a good question and Bart is correct that initializing and formatting disk units is no longer required as of more recent PTF levels.

At the time when those redbooks and redpapers were written, if you didn't first attach the target volumes and initialize and format them (with spectrum virtualize based storage such as IBM FlashSystem) they were on the target system as DPH units. This would cause the first switch to have the units fail to report in without resetting the virtual IOP or performing an IPL. 

With more current PTFs, this requirement was changed as the system will now process even those DPH units as part of a switch. You can see this reflected as well on the following page about adding units where it does not have you initialize and format on the backup system: https://helpsystemswiki.atlassian.net/wiki/spaces/IWT/pages/978223109/Adding+Disk+Units+in+an+SVC+Environment

You can similarly see on the more recent documentation for configuring asynchronous policy based replication with PowerHA that there are no steps for initializing and formatting disk units on the target system: https://helpsystemswiki.atlassian.net/wiki/spaces/IWT/pages/2990833680/Configuring+PowerHA+with+SVC+Asynchronous+Policy-based+Replication+7.5

Volumes from DS000 never had this behavior or requirement. 

Hmm, there are talking about just formatting disks. So, maybe it was an idea behind is to clear the disks which potentially were used for some other system before. 

I've never formatted the disks and has never issue with the iASP. But, I always had "new" LUNs from an external storage. 

Thanks Bartlomiej,

Yes, I had the same idea as your feedback, but in some IBM redbooks I found these sections:

In the redbook - PowerHA System Mirror for IBMi Cookbook / SG24-7994 - Jan 2012): 

Initializing IBM i disk units on the backup nodes Prior to setting up Copy Services on SVC/V7000

You have to initialize and format the read-protected DPHxxx disk units to become usable for the IASP on the IBM i backup nodes. This can be done in SST by choosing option 3 (Working with disk units), then selecting option 3 (Work with disk unit recovery), then selecting option 2 (Disk unit problem recovery procedure), and finally selecting option 1 (Initialize and format disk unit).

Failing to do so can result in IASP disk units not showing up properly after a switchover/failover to the secondary system

And a similar section was found in the Redpaper REDP4923 (2013)

And in fact, a similar question about the FlashCopy target luns of an IASP ... should these luns be initialized on the target FC partition (before arranging a FC) to assure the IASP can be activated.

Jozef,

You don't need/ you should not format the target disks on the target node. 

The proper sequence is: 

1. Create the iASP and add disks on the source node (this operation will format all LUNs but just on source node). 
2. Enable the replication between source and target.   

The replication process will copy all "0" and "1" to the DR disks, you don't need to worry about formatting. Obviously, initiating of the replication will hardly affect storage performance in both locations. 

All,

A question related to the setup of a new IASP under PowerHA/Metro mirror.

I have defined my IASP on the source node, but the metro mirror & powerHA setup still needs to be done.

Regarding the 'target' luns (of the metro mirror relationship) on the backup PT node, it is still recommended  or required (?) to init/format these luns first on the Backup node (only init & format), and afterwards continue with the metro mirror & powerHA setup.

Or should I consider this action as an additional validation of my storage assignments ? 

Thanks,

Kind regards,

Jos (Jozef) Thijs

Hi Jozef, In your scenario where a full system restore is being performed to a different partition, it's probably not going to be as easy as you have laid out.  
When performing a scratch restore (migrate) from old system/hardware to a new system/hardware, you would start out installing lic and initializing the system, then restoring the OS before you get the opportunity to CFGDEVASP.  However, if the full save was created from a system that was a member of a cluster, the CFGDEVASP will be prevented.  
Here is a document that covers the error and recovery:  https://www.ibm.com/support/pages/node/7175098

As far as the flashcopy target is concerned, if it was also scratch restored from old system/hardware to new system/hardware, you will need delete/recreate the previously know cluster information as it does not fully carry across where you can just start the cluster and CRG and session and be on your merry way.  
But you are correct in the sense that on your target, you would not CFGDEVASP.  You will need the IASP's *DEVD existing (CRTDEVASP if it doesn't exist) and the underlying storage configuration and cpyd information all needs to be accurate before attempting a new flashcopy.

If you have further/deeper questions or need further clarifications, I would highly recommend opening a case to IBMi Software Support to the HA team and we'd be more than happy to work further with you.

Bart, Brian, 

Thanks very much for your feedback.

Sorry, another question ... in the context of iasps.

In case of a full system restore operation (sysbase & iasp) on another server (migrating to new Power and new storage server)), I have to use the CFGDEVASP command (defined within my BRMS recovery report) only on the lpar, which functions as the source server within my PowerHA configuration. And afterwards, I can vary-on the iasp device, and continue with the restore operations of all libraries / dir in sysbase & iasp. 

On my new Target server (and new Flashcopy server), I don't have to use this CFGDEVASP command. Of course, I have to restore the sysbase completely, and I have to assure that the powerHA configuration (CRGs, ASP Copy descriptions) is well updated with the new storage server ip-address, and the new volumes.  And afterwards, starting my SVC session to startup the metro mirror ( or FC operation). Is my view here right ?

Afterwards, I change from primary site without any additional requirement ?

Thanks in advance for your feedback,

Kind regards,

Jos

This is a good question and Bart is correct that initializing and formatting disk units is no longer required as of more recent PTF levels.

At the time when those redbooks and redpapers were written, if you didn't first attach the target volumes and initialize and format them (with spectrum virtualize based storage such as IBM FlashSystem) they were on the target system as DPH units. This would cause the first switch to have the units fail to report in without resetting the virtual IOP or performing an IPL. 

With more current PTFs, this requirement was changed as the system will now process even those DPH units as part of a switch. You can see this reflected as well on the following page about adding units where it does not have you initialize and format on the backup system: https://helpsystemswiki.atlassian.net/wiki/spaces/IWT/pages/978223109/Adding+Disk+Units+in+an+SVC+Environment

You can similarly see on the more recent documentation for configuring asynchronous policy based replication with PowerHA that there are no steps for initializing and formatting disk units on the target system: https://helpsystemswiki.atlassian.net/wiki/spaces/IWT/pages/2990833680/Configuring+PowerHA+with+SVC+Asynchronous+Policy-based+Replication+7.5

Volumes from DS000 never had this behavior or requirement. 

Hmm, there are talking about just formatting disks. So, maybe it was an idea behind is to clear the disks which potentially were used for some other system before. 

I've never formatted the disks and has never issue with the iASP. But, I always had "new" LUNs from an external storage. 

Thanks Bartlomiej,

Yes, I had the same idea as your feedback, but in some IBM redbooks I found these sections:

In the redbook - PowerHA System Mirror for IBMi Cookbook / SG24-7994 - Jan 2012): 

Initializing IBM i disk units on the backup nodes Prior to setting up Copy Services on SVC/V7000

You have to initialize and format the read-protected DPHxxx disk units to become usable for the IASP on the IBM i backup nodes. This can be done in SST by choosing option 3 (Working with disk units), then selecting option 3 (Work with disk unit recovery), then selecting option 2 (Disk unit problem recovery procedure), and finally selecting option 1 (Initialize and format disk unit).

Failing to do so can result in IASP disk units not showing up properly after a switchover/failover to the secondary system

And a similar section was found in the Redpaper REDP4923 (2013)

And in fact, a similar question about the FlashCopy target luns of an IASP ... should these luns be initialized on the target FC partition (before arranging a FC) to assure the IASP can be activated.

Jozef,

You don't need/ you should not format the target disks on the target node. 

The proper sequence is: 

1. Create the iASP and add disks on the source node (this operation will format all LUNs but just on source node). 
2. Enable the replication between source and target.   

The replication process will copy all "0" and "1" to the DR disks, you don't need to worry about formatting. Obviously, initiating of the replication will hardly affect storage performance in both locations. 

All,

A question related to the setup of a new IASP under PowerHA/Metro mirror.

I have defined my IASP on the source node, but the metro mirror & powerHA setup still needs to be done.

Regarding the 'target' luns (of the metro mirror relationship) on the backup PT node, it is still recommended  or required (?) to init/format these luns first on the Backup node (only init & format), and afterwards continue with the metro mirror & powerHA setup.

Or should I consider this action as an additional validation of my storage assignments ? 

Thanks,

Kind regards,

Jos (Jozef) Thijs

Ben, 

Thanks very much for this valuable information. 

So, during this restore process for all 3 lpars (based on saves from lpars, being in a cluster), I have to delete the cluster completely from source, target and FC lpars ... and afterwards, recreate the cluster completely ( recovery domain / admin domain), CRGs, Cpy descriptions ... 

Thanks again,

Kind regards, 

Jos

Hi Jozef, In your scenario where a full system restore is being performed to a different partition, it's probably not going to be as easy as you have laid out.  
When performing a scratch restore (migrate) from old system/hardware to a new system/hardware, you would start out installing lic and initializing the system, then restoring the OS before you get the opportunity to CFGDEVASP.  However, if the full save was created from a system that was a member of a cluster, the CFGDEVASP will be prevented.  
Here is a document that covers the error and recovery:  https://www.ibm.com/support/pages/node/7175098

As far as the flashcopy target is concerned, if it was also scratch restored from old system/hardware to new system/hardware, you will need delete/recreate the previously know cluster information as it does not fully carry across where you can just start the cluster and CRG and session and be on your merry way.  
But you are correct in the sense that on your target, you would not CFGDEVASP.  You will need the IASP's *DEVD existing (CRTDEVASP if it doesn't exist) and the underlying storage configuration and cpyd information all needs to be accurate before attempting a new flashcopy.

If you have further/deeper questions or need further clarifications, I would highly recommend opening a case to IBMi Software Support to the HA team and we'd be more than happy to work further with you.

Bart, Brian, 

Thanks very much for your feedback.

Sorry, another question ... in the context of iasps.

In case of a full system restore operation (sysbase & iasp) on another server (migrating to new Power and new storage server)), I have to use the CFGDEVASP command (defined within my BRMS recovery report) only on the lpar, which functions as the source server within my PowerHA configuration. And afterwards, I can vary-on the iasp device, and continue with the restore operations of all libraries / dir in sysbase & iasp. 

On my new Target server (and new Flashcopy server), I don't have to use this CFGDEVASP command. Of course, I have to restore the sysbase completely, and I have to assure that the powerHA configuration (CRGs, ASP Copy descriptions) is well updated with the new storage server ip-address, and the new volumes.  And afterwards, starting my SVC session to startup the metro mirror ( or FC operation). Is my view here right ?

Afterwards, I change from primary site without any additional requirement ?

Thanks in advance for your feedback,

Kind regards,

Jos

This is a good question and Bart is correct that initializing and formatting disk units is no longer required as of more recent PTF levels.

At the time when those redbooks and redpapers were written, if you didn't first attach the target volumes and initialize and format them (with spectrum virtualize based storage such as IBM FlashSystem) they were on the target system as DPH units. This would cause the first switch to have the units fail to report in without resetting the virtual IOP or performing an IPL. 

With more current PTFs, this requirement was changed as the system will now process even those DPH units as part of a switch. You can see this reflected as well on the following page about adding units where it does not have you initialize and format on the backup system: https://helpsystemswiki.atlassian.net/wiki/spaces/IWT/pages/978223109/Adding+Disk+Units+in+an+SVC+Environment

You can similarly see on the more recent documentation for configuring asynchronous policy based replication with PowerHA that there are no steps for initializing and formatting disk units on the target system: https://helpsystemswiki.atlassian.net/wiki/spaces/IWT/pages/2990833680/Configuring+PowerHA+with+SVC+Asynchronous+Policy-based+Replication+7.5

Volumes from DS000 never had this behavior or requirement. 

Hmm, there are talking about just formatting disks. So, maybe it was an idea behind is to clear the disks which potentially were used for some other system before. 

I've never formatted the disks and has never issue with the iASP. But, I always had "new" LUNs from an external storage. 

Thanks Bartlomiej,

Yes, I had the same idea as your feedback, but in some IBM redbooks I found these sections:

In the redbook - PowerHA System Mirror for IBMi Cookbook / SG24-7994 - Jan 2012): 

Initializing IBM i disk units on the backup nodes Prior to setting up Copy Services on SVC/V7000

You have to initialize and format the read-protected DPHxxx disk units to become usable for the IASP on the IBM i backup nodes. This can be done in SST by choosing option 3 (Working with disk units), then selecting option 3 (Work with disk unit recovery), then selecting option 2 (Disk unit problem recovery procedure), and finally selecting option 1 (Initialize and format disk unit).

Failing to do so can result in IASP disk units not showing up properly after a switchover/failover to the secondary system

And a similar section was found in the Redpaper REDP4923 (2013)

And in fact, a similar question about the FlashCopy target luns of an IASP ... should these luns be initialized on the target FC partition (before arranging a FC) to assure the IASP can be activated.

Jozef,

You don't need/ you should not format the target disks on the target node. 

The proper sequence is: 

1. Create the iASP and add disks on the source node (this operation will format all LUNs but just on source node). 
2. Enable the replication between source and target.   

The replication process will copy all "0" and "1" to the DR disks, you don't need to worry about formatting. Obviously, initiating of the replication will hardly affect storage performance in both locations. 

All,

A question related to the setup of a new IASP under PowerHA/Metro mirror.

I have defined my IASP on the source node, but the metro mirror & powerHA setup still needs to be done.

Regarding the 'target' luns (of the metro mirror relationship) on the backup PT node, it is still recommended  or required (?) to init/format these luns first on the Backup node (only init & format), and afterwards continue with the metro mirror & powerHA setup.

Or should I consider this action as an additional validation of my storage assignments ? 

Thanks,

Kind regards,

Jos (Jozef) Thijs