Yes well at least in theory
As long as snapshot matches <SNAME>-<SNAP_TYPE>_recent or <something>-<something>_YYYYMMDDhhmmss
SNAME is set in sc config and SNAP_TYPE is policy so set with --policy for example if SNAME=test and --policy daily it would be test-daily_recent or test_daily_<YYMMDDhhmmss>
What you could do if you can create a snapshot SC understands is set following:
NTAP_SNAPSHOT_DISABLE=Y
NTAP_SNAPSHOT_NODELETE=Y
This would ensure SC doesnt create snapshot and doesnt delete snapshot
Next enable protection manager:
NTAP_PM_UPDATE=Y
NTAP_DFM_DATA_SET=<filer name>:<dataset name>/<list of volumes in dataset separated by commas>
SC now should use your snapshot and register it in PM since there is nothing else to do.
However _recent wont work since though SC could register it in PM it wont be unique and PM cant handle that, meaning snapshot name must always be unique so you have to use timestamp.
In SC you can override timestamp by setting SNAP_TIME. I would do this in config:
SNAP_TIME=%USER_DEFINED
and then from cli use --user_defined <timestamp>
Again this is all theory...we never tested this but the chances of something working are at least 50/50 and it sure doesnt hurt to try
If you get things working there is another interesting option
NTAP_PM_RUN_BACKUP=Y
This will cause SC to actually kick off PM job after snapshot is registered, this removes PAIN in all other SnapManager integrations with PM of having two different schedules, so SC can drive everything. SC will even wait for PM job to complete and tell you if it succeeded or failed.
Let us know if this helps or you get this working
Regards,
Keith