#Convert SVM Relationship to Volume Relationships

1 messages · Page 1 of 1 (latest)

hallow sandal
#

Hello, I'm having trouble finding documentation on how to convert an SVMDR relationship into regular SnapMirror relationships. There is a guide on how to convert volume to SVM but not the other way around.

silver wadi
#

I mean you could try some volume rehost/resync trickery maybe? But officially it's not supported

radiant monolith
#

That’s awful! It used to be supported/work.
You could delete the snapmirror relationship but keep the snapshots. Then when you create a new volume snapmirror you reference the known snapshot. But for that matter you could use any common snapshot (hourly/weekly/etc) as long as it exists on both sides. One side would be “reverted” and then snapmirror works catch it up. I’ve done this in the past. I can’t believe it’s not supported now!

silver wadi
#

I think I tried it a while ago and it got stuck somewhere... maybe @graceful pawn remembers? something just didn't work but I don't remember the specifics

graceful pawn
#

These were the steps from my colleague:

  1. create new SVM on destination cluster
  2. change SVM-DR from "identity-preserve=true" to "identity-preserve=false"
  3. delete CIFS LIF in destination SVM
  4. snapmirror break on destination cluster to change subtype of destination SVM from "dp-destination" to "default"
  5. snapmirror release -relationship-info-only true on source cluster
  6. vol unmount of destination volumes
  7. vol rehost into new SVM
  8. create vserver peers to new SVM
  9. rename volumes on destination cluster
  10. create regular snapmirror relationships (vault) between the volumes
  11. snapmirror resync
#

You could also simply reuse the destination SVM after the snapmirror break, I think he tried that too.

silver wadi
half condor
#

The procedure has been moved to internal only with this warning, "This procedure may result in data loss if not implemented exactly as described. The steps should only be performed under direct supervision of Level II Data Protection support." The, "may result in data loss" means it has resulted in data loss for at least one, and more likely more than one, customer. Open a case and talk to support for that one.

silver wadi
#

fair enough, thanks for looking. Sometimes I wonder why commands like "volume delete" or "aggregate delete" are allowed, I'm pretty sure those have also resulted in data loss for at least some people 😉

#

I mean you can't babysit admins forever 🙈

half condor
#

😁

#

You are talking to the one person in support who has a project to move as much of the internal KB content as possible to customer facing. It's a big project, but, even still, there are some things I will not be able to move. Just too much risk. Having said that, I see there is an RFE opened to code up a solution to support this: CONTAP-84000. No target yet for release. I will let them know there was interest expressed in this thread.

silver wadi
# half condor You are talking to the one person in support who has a project to move as much o...

I know, and I really appreciate what you're doing. It's just that more often than not it seems like the many little cogs that are at work in different parts of NetApp turn in just the wrong direction to be really helpful.
Example. The BURT you referenced, I am pretty sure I could give you at least 5 customers who would love to have that feature. More customers attached to a BURT makes it higher priority (or so I've heard). The problem is that I cannoot just do that, for the simple reason that we are an SSC (now LSC) partner and we get rated on the number of cases we open with NetApp for our customers. We can open approximately 1% of the number of installed systems as cases per month, so with, say, 1000 systems under LSC we can open 10 cases before we're getting rated negatively (and risk to lose some 10% of rebates when selling new systems, which would be devastating).
So even though I know that I have customers waiting for that features, and I know that opening cases and asking to attach them to that BURT would be beneficial, I'm incentivized to not do that.

#

I mean I can understand both sides (prioritizing BURTs with more customers impacted, as well as incentivizing partners solving their own cases and not just delegating everything back to NetApp support) but in cases like that, it is just annoying

half condor
#

email is my name as you see it above @distant kraken.com in case I miss it here.

distant krakenBOT
half condor
#

whatever

dense glade
silver wadi
#

Yeah, that is something we can do. But the FPVR process is also something that's not very well-documented from what I understand: there's documents and forms that you have to fill out, and getting those requires you to ask the SE at NetApp assigned to that customer...). I think it would be helpful if there was an easy way that we (as a partner) could follow ourselves (without involving NetApp SE's) and of the documents were available to us directly

half condor
#

We will start a conversation with the powers that be and figure something out. Have some ideas to kick of the conversation with, but too early to share yet. I think this sounds like a worthwhile area to improve.

lime cedar
#

@dense glade would you be ok with the steps being documented here at least? I don't think it's a problem. Maybe we could move those steps to the partner section?

dense glade
#

No. I don't think it's a good idea to publish unsupported steps.