I'm in the process of moving over datasets from one DFM instance to another and all is going well except when I imported the relationships on 2 datasets that do a cascade. From node A to node B, the import went fine and picked up where it left off, but from point B to point C, it created another volume and reinitalized. This is not supposed to happen. I relinquished all the relationships between A and B and between B and C and imported them specifying the correct node. Is this a bug? I'm using OpsMgr 4.0.2.
The relinquish and import commands I used were like this:
First let me give the reason why you faced this. In your case you have a cascade topology of A>B>C. And you tried to import the relationship form A>B. PM created the relationship from B>C, following are the reasons.
This is the way PM's conformance engine is designed to do this. It finds that as per the dataset for any member in the primary of the dataset it needs to have a relationship in the node B and C.So when you import the leg from A>B conformance kicks in when you finish the import wizard/cli, it finds that there is no relationship from B>C and go heads and creates it if you have resource pool or a volume attached to the node C.
I agree that PM should have warned about this so that it can be avoided, if you import the leg from B>C first then PM conformance would have not done this, because there is no member on the primary to check if on the secondary (B) and tertiary (C) relationship needs to be create
Happy to help you.Still I strongly feel this as a bug, as Pete said the conformance should have warned you about the downstream relationship creation when you finished importing the leg A>B. I am filing the bug for the same. Can you add your case to bug594423 ?
Also the same will happen in case of a fan out topology as well. i.e A >B and A> C and its little tricky as we cant do the same here like the A>B>C by importing B>C first and A>B later. The only way I can think off is by suspending the dataset and importing either of A>B or A>C and once completed resume the dataset.
I have encountered something similar. I have a cascading primary>mirror>backup/vault relationship established on a dataset. I need to move the volumes in that dataset to another dataset with a similar cascading protection scheme (using the same Protection Policy in fact). After removing the volume from the dataset (taking the volumes out of the Physical Resources of the Primary, Mirror, and Backup lists) I can see both the snapmirror and snapvault entries in the External Relationships list.
However, if I try to import using the snapmirror entry, PM wants to create a new vault volume and rebasline/reinitialize. Which I understand and matches your above explanation.
If I try to import using the snapvault entry, it won't let me select the the volume and add it to the dataset (says it is "Not applicable to the Selected Connection).
If I try to import using both entries (ctrl click to highlight both), I can only add the mirror and not the vault, getting the same error message for the vault.
How so I put the entire cascade into the new dataset?
Absolutely wonderful! I wasn't aware you could move the "box" in the upper portion of the import wizard screen. Tested on a small volume and it worked perfectly.
One note of warning to anyone doing this - there is a process in the background, dfmreaper I believe, that will remove the relationships from the External Relationship window within a certain time frame. Just make sure to quickly import the relationships to your new dataset.