SnapMirror target vol name change, SM updates failing now

[jntballard]

Although I have registered the relationship with PM, I am currenlty using SnapCreator to do the SnapMirror updates, PM schedules have been set to 'none'.  The admin changed the names on the target volumes in the SnapMirror releationship.  The volume names have been updated on the DR NetApp, the snapmirror.conf has been updated, snapmirror status reflects the new volumes correctly.  PM now reflects the new volume names within the dataset for the relationship to the DR target NetApp too.  I can run a snapmirror update from the command line, no problem.

SnapCreator fails with the following error:  Wed Jul  6 14:06:20 2011] [scf-00013] NetApp Snapmirror Update on destination netapp-spo-c2a:vol_srp_arch_SnapMirror failed!

SnapCreator is still referencing the old volume name.  Where is SnapCreator retrieving the vol name for the SnapMirror update? 

I thought it may have been in the config file, not the case...

Thanks -

[ktenzer]

SC does not get secondary volumes from config. In config you only specify primary in VOLUMES and SNAPMIRROR_VOLUMES parameters. SC does a snapmirror status on primary and checks secondary relationships based on primary volume, it is done dynamically.

In this case the old snapmirror relationships must still exist at least on primary, maybe you only removed relationship on secondary and didnt cleanup primary? Do snapmirror status on primary and verify.

Regards,

Keith

[jntballard]

Figured it out...

On the source NetApp, the 'snapmirror destinatios' has to be updated too.  It will keep the original volume name until you 'release' the relationship and run another 'snapmirror update'.

Basically, on the source:

- Type:  snapmirror destinations

- Release the destinations: snapmirror release  <srcpath> <dstfiler>:<dstpath>

On DR NetApp:

- Type: snapmirror update <dstfiler_volname>

This will now update the 'snapmirror destinations' on the source NetApp, and the next run of SnapCreator will run succesfully without errors...

[ktenzer]

From SC perspective the most important thing is you do a release on primary. SC determines secondary by looking at snapmirror status on primary.

Regards,

Keith

[jntballard]

Interesting... until I updated the 'snapmirror destinations' to also reflect the new volume relationship, it was still referencing the old volume.

I had about 12 volumes that were changed... I can test this again on Friday from scratch to ensure I have all of the caveats identified correctly.

One other item,  before a snapmirror release is performed, make sure a 'snapmirror update' is done.  Otherwise the base SnapShot will have the old volume relationship name and you will have to do a 'snapmirror initialize' if you mess up the base snap.

Thanks -

Jerry

[ktenzer]

Thanks for info Jerry

I know SC keys off snapmirror status but it could be that maybe old names were being cached and until you updated snapmirror destinations they weren't removed.

Definitely good info to share w/community

Keith