#Clone volume split failing - Error 13171

1 messages · Page 1 of 1 (latest)

golden egret
#

Hello,
I have a volume I'm using for an NFS share, that is currently a clone of a previous snapmirror volume. I'm trying to "split" the clone, but I get an error saying "ONTAP API FAILED. Clone volume is not being split from its parent. (Error: 13171). I tried searching for this error code, but found nothing.

Anyone knows what could be the problem? Will I have to shutdown (set to offline) the volume before I try to split?

The original volume was a snapmirror vault of a volume on a different netapp controller. Then I cloned it and am now trying to delete the old one.

Thank you for your help!

final mason
#

probably not enough space or something. You might need to try the command on the CLI to see the exact error (volume clone split start -vserver ... -flexclone ...)

#

or maybe the split is running but has not finisehd yet

golden egret
#

Thanks, I did it on the CLI and got the same simple error message, but then I checked the jobs tab on the GUI and it said "Volume has locked snapshots" so I guess that's why it is failing

#

Hmm, one of the snapshots says "busy" on the status. It's the snapshot I used to clone the volume. I can't seem to delete it or unlock it.

#

At least through the GUI

final mason
#

yeah you can only delete that busy snapshot after the split has completed, which makes me think that it might still be running (or not even started)

#

what does volume clone split show say?

golden egret
#

Seems to be failing the spli still. It just says that simple message.

#

I checked the estimate of the same needed and it only needs 23MB, which I do have both on the aggregate and the parent volume.

#

I'll add a bit more space to check, but it doesn't seem to be a space problem either.

final mason
#

hm. strange. Can you check job show -id 13495and/or event log show -event *liferay_data*

#

don't think it's free space as that should give a different error

golden egret
#

Got "there are no entries matching your query" on both.
On the GUI, in the jobs section I get "Volume has locked snapshots". Could it be because the parent is a DP volume?

golden egret
#

Got the existing old snapshots, which are not busy, and the busy snapshot that I used to clone this volume.

#

Thanks for the kb links, I'll read them

#

The fields "tags" and "dependency" said "invalid argument"

karmic solar
#

Do set diag

#

Does the SM-relationship with your DP-volume still exist? Is there maybe a SM schedule configured which tries to update it before your split is done?

#

If you don't need the SM-relationship anymore, do a snapmirror delete on the destination and snapmirror release -relationship-info-only true on the source cluster. Then try to split again

golden egret
#

No, I broke the relationship before I created the clone. In fact, I only created the clone because I couldn't turn the DP volume into a RW after deleting the relationship, so I had to make a clone.

karmic solar
#

If you only broke the relationship it still exists. Does it show up in snapmirror show?

golden egret
#

I used set diag, for some reason dependency is still not an available option, but tags is.

#

I'll check

karmic solar
#

The dependency field is hidden, you need to write it out, no autocomplete. But doesn't matter. You have the SMcreated tag so most likely that's the issue. Do the SM delete and SM release combination from above.

#

In the future if you need a clone from a DP-vol I would recommend to create a new snapshot and then clone from that one.

golden egret
#

Yeah, the source controller is still saying the snapmirror is there. I'll delete it

final mason
#

on the source you can see the SnapMirrors with snapmirror list-destinations

golden egret
#

I misread it, it did not in fact have a relationship there still. The only thing I managed to do sucessfully was to "break" the relationship. But can't delete nor release, because there's no relationship anymore.
Even after this break, the split is still failing. Do I need to change the tag on the snapshot?

#

Result with the dependency field

#

Is it because I'm already replicating this new volume to a different netapp that is causing this? I cloned it, then replicated, before trying to split.

karmic solar
#

But something changed though: snapmirror is no owner anymore on the snapmirror-snapshot

#

So just to confirm, both these CMDs give no output?
On source-cluster: snapmirror list-destinations -destination-path A220-SVM2-NFS:SAS_NFS_GOGIN_p01srv02_liferay_data_dest
On destination-cluster: snapmirror show -destination-path A220-SVM2-NFS:SAS_NFS_GOGIN_p01srv02_liferay_data_dest

And this does not work, on the destination-cluster: snapshot delete -vserver A220-SVM2-NFS -volume SAS_NFS_GOGIN_p01srv02_liferay_data_dest -snapshot [snapmirror-snapshot-name] -ignore-owners true -force true

correct?

golden egret
#

The first two return "there are no entries matching your query. I had not tried to the delete the snapshot through CLI yet, but I got an error. Still saying it's locked, no expiry time apparently.

#

Thanks again your help btw.

golden egret
#

(I changed the name of the snapshot to make it more readable)

karmic solar
#

Ok wait that was stupid, of course you can't delete that snapshot, it's the base of your clone... 🤦
Is this a DP or RW clone? If DP I would suggest to delete the clone, create a new snapshot on the original volume, and clone + split from the new snapshot. Once that's done delete the original volume.

golden egret
#

When I cloned it, the original volume was DP (that was actually why I felt the need to clone it). Now it is saying RW, must have happened after I managed to run the "break" command on the relationship.
The cloned volume is already in production. I'm unsure of how clones work. Do the changes in the cloned volume replicate to the original automatically? Because otherwise, I can't just delete this new clone.

karmic solar
#

No I meant the clone volume, does it have type RW?

golden egret
#

Yes

karmic solar
#

If yes, all new writes are associated to the clone vol, all existing blocks are only referenced from the original volume.

golden egret
#

So I shouldn't delete it, right?

karmic solar
karmic solar
#

You still get the same error when you do the vol clone split start?

#

It's a bit difficult to troubleshoot this without remote session 😉
Best to create a NetApp case if it's critical.

golden egret
#

Yeah, it's being used in production as an NFS share. I'll try again.

#

You're right and I appreciate your help. It's not really critical, it's just annoying having those dead volumes there that I cloned from. I thought I had just made a simple error that you guys would quickly find, but turns out the error was when I cloned the volume in the first place, so it's tough now.

golden egret
#

So the problem really was the replications. But it was the new replications I started from the clones. When I deleted those replications and tried the clone split, it worked.

#

Unfortunately I got myself into a different error now. When I did the clone splits, they all worked except for one. The one that didn't work, the original volume that it was cloned from was offline, which is why I think the splitting failed. Unfortunately now when I try to split again I get "ONTAP API Failed: The volume is temporarily unavailable, please try again (Error: 13114)". Any suggestions? Do I have to put it offline and then back online?

karmic solar
#

Yes, it needs to be online

golden egret
#

The problem is it is now online, but I still get that "volume is temporarily unavailable". You think turning it offline and then online would solve it?