Hi Tim,

Are you using dynamic SRDF (check with "symrdf list -dynamic" and see if any of your existing devices are listed)? If so, use a "symrdf createpair" to pair up your devices creating the corresponding R1 & R2's.

If not, then the symconfigure command you gave will do what you want.

Either way, adding SRDF will not impact the host. However the resync will push up the utilisation of the SRDF links which could potentially increase the service time of your existing SRDF/S devices. Best practice is to also put the new devices in "Adaptive Copy Disk" mode whilst they sync up. This prevents acknowledgements of new writes to those volumes being delayed during the sync.

The impact may be negligible - but to be safe do it out of hours and use something like "sar" to check whether there is any impact. You'll then know for next time.

Best Regards,
Marc

Hi Tim,
Can't see from your post if you're running SRDF/A so ignore this if you're running Sync.

If you're running SRDF/A & already have RDF devices in ra group 1 that are consistent
you'll have to take them out of async mode prior to adding more devices to that ra group.

If you don't, you'll see this error when you try to run the symconfigure/convert "The request is not allowed for SRDF/A-capable devices in async mode."

This is a restriction where all devices in an ra group running SRDF/A must be managed together.

So just drop your group into adaptive copy disk mode :-
# symrdf -g yourgroup set mode acp_disk -nop

Then run your convert command.

I only mention this because, in one of the environments I work in this is classed as an offline change because even though the R1 volumes all remain available to the production servers there is an impact in terms of DR because the R2's spend a period of time in adaptive copy mode.

Regards
Ben

Tim if you really want to avoid any possible impact on the hosts, you can also use the symqos command and slow down the RDF copy pace, just to reduce further the little impact that Marc already explained.