nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Used disk added to another netapp seem to be in aggregate after owner change, not as spare

MarkusWs

I have three old - thus unsupported NetApp Maschines - which are to nice to put them into the trash. The three systems share the same disk type and size so I decided to power off one of these machines and use the disks as replacement for the two others (a metro cluster) to keep it running for "secondary storage". So recently the first disk failed so I put one disk into it but, after setting the owner to the new system, it seems to be in in aggregate:

so a part of the disks look like these with disk show:

4.52.2 3.63TB 52 2 FSAS aggregate aggr0_<systemname> <systemname>
4.52.3 3.63TB 52 3 FSAS aggregate aggr0 <systemname>
4.52.4 3.63TB 52 4 FSAS aggregate aggr0_<systemname> <systemname>

I replaced the name of the system with "<systemname>". So the old, powerer off machine had one huge "aggr0", and the machine I am adding to has the aggr0 renamed to aggr0_systemname as it is, unlike the powered off, part of a metro cluster.

So the 4.52.3 is the disk I replaced and reowned, but it does not appear as spar disk, it remains in "aggr0" (which does not exist on this system). How can I make it a spare disk?

Find more posts tagged with

Accepted answers

Ontapforrum

Sounds great. Give it a go and let us know if that solves the issue, this may help others facing the similar issue.

All comments

Ontapforrum

Check this kb:

https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/How_to_remove_ownership_on_foreign_disks_in_clustered_Data_ONTAP

MarkusWs

Sorry that it took me so long to answer, but in the meanwhile first Covid hit me, than the holiday season. So I got finally today to the point to check out the KB article - but it does not help. The storage storage disk modify does not exist even in diag mode on the systems.
The metrocluster commands mentions only bring the id of the disk which I already knew and not these which are in the not existing aggregate, but no way to move either - the completely unassigned, nor these which I assigned to the correct owner but which are in that non-existing aggr0.
See screenshots attached.

Ontapforrum

I have also lost track of your original query , anyway hope you are feeling better now. I checked, modify do not show up, but there is removeowner, not sure if that helps.

try ::>storage disk removeowner
https://docs.netapp.com/us-en/ontap-cli-96/storage-disk-removeowner.html#description

MarkusWs

Thanks for your quick reply. My problem is not to remove the old owner. I can do this. But if I assign it to the correct vserver, it becomes member of an not existing aggregate.

Ontapforrum

Could be b'cos it was previously a part of a different system and still contains information from those aggregates (non-existing in the current setup), something messed up. If possible - Move the drive back to the previous system and then remove ownership of them and make it a spare and then bring it over.

Ontapforrum

There is one kb which is similar to your issue. I don't know if it that's the cause.

Disks falsely showing as used in aggregate in 'disk show' - NetApp Knowledge Base

MarkusWs

Yes, that KB article sound like my issue - but I do not hae any support any more on this system. I cannot move the disks back to the old system, and that would not help either as it had only one huge aggregate, which you cannot destroy and remove disk from, as it contains the root volume.

MarkusWs

So, I found the solution!

The trick is:

assign the disk, so they will apprear to be in my case in the non existing aggr0

priv -set diag

aggr remove-stale-record -aggregate aggr0 -node <thenode>

And finally the disk will be a spare!

Ontapforrum

Sounds great. Give it a go and let us know if that solves the issue, this may help others facing the similar issue.