I'm not aware of any changes in OC5 that would cause it to purge snapmirror.conf, but perhaps something changed that I'm not aware of.
If you enable SnapMirror compression by editing snapmirror.conf, those changes can be erased if you use the hostPreferredAddr options. This is a known problem and should have been mentioned in the TR.
Instead the schedule are driven by DFM server scheduler service which does the scheduling as per the policy you use in PM.
If you have the option hostPreferredAddr1/2 set in DFM for the source and destination filer of Snapmirror.And create a VSM or QSM relationship using PM then PM creates a connection and make these entries in snapmirror.conf
It is advised to remove the schedule in the snapmirror.conf to remove the redundant scheduling. Make sure that hostPreferredAddr1/2 are not set on the source and destination filer of the compression enabled snapmirror filers in DFM.
When a relationship is imported say like below which has snapmirror.conf entry as follows
The reason why hostPreferredAddr1/2 should not be set for compression enabled snapmirror is because before every transfer we rewrite the snapmirror.conf with the above two entry in this process compression options is deleted as there is no support for it in NDMP or api.
I had originally asked....how would you go about retrofitting existing PM created relationships to enable compression? I subsequently worked that out....here are the steps...
* add dfm host set <hostname> hostPreferredAddr1=x.x.x. to each source node's configuration within DFM
* manually edit the /etc/snapmirror.conf file to populate it using the output of "snapmirror status" for source/destination pairings
* remember to add the "compression=enable" in the options field and to keep the schedule - - - -
* remember to configure your connection string settings
* I use a text editor to fully create the file structure, then paste it into the CLI using "wrfile /etc/snapmirror.conf" & ctrl-c
Once you do those steps, Protection Manager will use compression the next time it updates. This process assumes you have pre-existing datasets with policies defined and mirrors baselined/updating. If you need to configure new relationships, Protection Manager will populate the snapmirror.conf file (thanks to the hostPreferredAddr1 setting) and all you need to do is edit the configuration file to change the source node name to the connection string and add the compression option.
NOTE - an initialize process will NOT be compressed because Protection Manager cannot enable compression as pointed out in previous comments. Unless you create the relationship using System Manager without initializing, make the changes to snapmirror.conf, manually initialize, then import as outlined in Adai's post, you cannot initialize using compression. I hope this helps the next person to ask the question!
Thanks to Adai for getting me on the right track with his posting about preferred addresses.