I've recently discovered what I believe is a bug in System Manager's SnapMirror control. I currently implement a SnapMirror DR scenario and recently simulated a disaster to ensure there would be no problems in the event of a true disaster. I cold powered down my source filer and attempted to quiesce and break the SnapMirror relationship on the destination so I could recover and mount the mirrored volumes into my VMWare environment. System Manager wouldn't allow me to do ANYTHING with the SnapMirror relationships (all options are grayed out) because it wants access to the source filer which is now "gone" in my scenario. I'm able to quiesce and break these relationships from the command line and continue with my test that way. My question is, has anyone else experienced this and is this considered to be a bug?
I've reported this to my NetApp rep who is working with the System Manager developers to determine if this is a bug or by design. Why they would design the software this way when the bulk of its existence being to be used in DR scenarios is beyond me, and I hope that's not the case.
Most of what we do where I work (Army) is for documenting procedures for troops who may not be as technically efficient as the engineers developing these solutions. So GUIs are important to us because we have to make the assumption that the "admins" we are training are not as geeky as we are. Simply always using the command line is not acceptable for what I do. I personally use the CLI all the time, but it's not practical for our military solution. Thanks though.
Hi mate, just saw your post for which I think you don't expect any post any more. quick question, is the relationship was in snapmirror.conf too? or it was a one go test, no schedule just on demand relationship?