Could you paste volume show -instance for the volume in question? Doing it in diag mode may show even more. ... View more

Snapshots migrated from 7-Mode likely cannot be converted - they are read-only by definition. ... View more

Online removal is supported only for completely unused shelves. What you are doing is effectively removing shelves from stack. Go figure ... ... View more

The answer is a bit complicated. In general, "thin provisioned" implies "no space reservation", so  it may happen that volume runs out of space because it will be filled by other data (e.g. other LUN, snapshots etc). See TR-3483 for detailed description of LUN space management on NetApp.   P.S. I edited reply and corrected TR number. ... View more

Did you enable de duplication on SV secondary from the very beginning? Did you run sis start -s on secondary? ... View more

I swear I have seen VSM destinations stay 32 bit like their source Conversion starts after snapmirror break; did you do it? ... View more

You are right of course. I do not know whay I was sure we need 8.1 source to perform 32 to 64 bit VSM; it is only reverse sync that requires it. Thank you! ... View more

Yes, that's possible. Do not forget, that in-place conversion without increasing aggregate size beyond 16T is officially supported starting with 8.2.1 if my memory serves me right. ... View more

If you could not take an outage, you would not single controller. If you update source to 8.1 you can use VSM from 32 to 64 bit. ... View more

Can you update to 8.1 or newer? ... View more

An aggregate with the accompanying volumes in 7-mode are fully self described by the WAFL filesystem on the disks.  In cDot, they are not.  The cluster database, a copy of which is maintained on all nodes in the cluster, contains a ton of reference pointers as to what is where, what SVMs stuff belongs to, other relationship data, etc. That's not quite correct. Aggregate still contains enough information and there is tool to compare WAFL and VLDB and fix descrepances. May be this tool could even be used to introduce foreign aggregates and volumes into cluster. I do not have equipment to test it. There is no mechanism or utility that exists to map/merge 7-mode generic volumes into a cluster, building up the cDot metadata and ownership as you go. The question was how to move cDOT aggregate from one to another filer. At least that is how I understood it. Not how to import 7-Mode aggregate. ... View more

What is content of /etc/nsswitch.conf and CIFS setup mode? ... View more

I am not aware of any way to move cDOT aggregate to a different filer. The only possibility is aggregate relocation, which effectively simply reassigns ownership to a partner in HA pair. This is one of features I really miss comparing with 7-Mode. ... View more

That's not possible. For a start, SVMs do not even exist in 7-Mode ... ... View more

Look at https://kb.netapp.com/support/index?page=content&id=3012724 In particular Sessions established to NIS, LDAP, AD, WINS, DNS, NDMP, iSNS/Radius servers use any of the Data LIFs per vserver on the node.   ... View more

Thank you for sharing! ... View more

OK, I can confirm that in 8.3 you can create SnapVault policy that will transfer only named snapshots from SnapMirror destination. Here is configuration: cluster2::> snapmirror show -fields source-path,destination-path,type,policy source-path destination-path type policy ----------------- ---------------- ---- -------------------- svm_dst1:smv_dst1 svm_dst1:vault XDP Test_Named_Snapshots svm_src1:snap_src1 svm_dst1:smv_dst1 DP MirrorAllSnapshots 2 entries were displayed. cluster2::> snapshot policy show -vserver cluster2 -policy -policy -policy-owner cluster2::> snapmirror policy show Test_Named_Snapshots Vserver Policy Policy Number Transfer Name Name Type Of Rules Tries Priority Comment ------- ------------------ ------ -------- ----- -------- ---------- cluster2 Test_Named_Snapshots vault 2 8 normal - SnapMirror Label: label1 Keep: 15 label2 25 Total Keep: 40 cluster2::> snapshot show -vserver svm_dst1 -volume vault ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- svm_dst1 vault snap_src1 160KB 0% 40% label1.1 124KB 0% 34% label2.1 124KB 0% 34% snapmirror.03770f75-296f-11e4-8232-005056011732_2147484674.2015-07-17_074500 92KB 0% 28% 4 entries were displayed. So I have SnapMirror from another SVM on another cluster and SnapVault to the second volume in the same destination SVM. SnapVault has policy that transfers only named snapshots. Now try to create a couple more and update destinations. cluster1::> snapshot create -vserver svm_src1 -volume snap_src1 -snapshot label1.one-more-snapshot -snapmirror-label label1 cluster1::> snapshot create -vserver svm_src1 -volume snap_src1 -snapshot some-other-snapshot -snapmirror-label label2 cluster1::> snapshot show -vserver svm_src1 -volume snap_src1 ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- svm_src1 snap_src1 snap_src1 160KB 0% 14% daily.2014-11-08_0010 284KB 0% 23% weekly.2014-11-23_0015 352KB 0% 27% weekly.2014-11-30_0015 272KB 0% 22% daily.2014-12-03_0010 220KB 0% 18% daily.2014-12-04_0010 112KB 0% 10% hourly.2014-12-04_1205 88KB 0% 8% hourly.2014-12-04_1305 84KB 0% 8% hourly.2014-12-04_1405 84KB 0% 8% hourly.2014-12-04_1505 88KB 0% 8% hourly.2014-12-04_1605 184KB 0% 16% hourly.2015-07-17_0705 104KB 0% 10% label1.1 88KB 0% 8% label2.1 84KB 0% 8% snapmirror.03770f75-296f-11e4-8232-005056011732_2147484674.2015-07-17_074500 84KB 0% 8% snapmirror.03770f75-296f-11e4-8232-005056011732_2147484674.2015-07-17_080000 92KB 0% 9% ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- svm_src1 snap_src1 label1.one-more-snapshot 92KB 0% 9% some-other-snapshot 64KB 0% 6% 18 entries were displayed. cluster2::> snapshot show -vserver svm_dst1 -volume smv_dst1 ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- svm_dst1 smv_dst1 snap_src1 160KB 0% 14% daily.2014-11-08_0010 284KB 0% 22% weekly.2014-11-23_0015 352KB 0% 26% weekly.2014-11-30_0015 272KB 0% 22% daily.2014-12-03_0010 220KB 0% 18% daily.2014-12-04_0010 112KB 0% 10% hourly.2014-12-04_1205 88KB 0% 8% hourly.2014-12-04_1305 84KB 0% 8% hourly.2014-12-04_1405 84KB 0% 8% hourly.2014-12-04_1505 88KB 0% 8% hourly.2014-12-04_1605 184KB 0% 16% hourly.2015-07-17_0705 104KB 0% 10% label1.1 88KB 0% 8% label2.1 84KB 0% 8% snapmirror.03770f75-296f-11e4-8232-005056011732_2147484674.2015-07-17_074500 84KB 0% 8% snapmirror.03770f75-296f-11e4-8232-005056011732_2147484674.2015-07-17_075500 96KB 0% 9% ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- svm_dst1 smv_dst1 snapmirror.03770f75-296f-11e4-8232-005056011732_2147484674.2015-07-17_080000 0B 0% 0% 17 entries were displayed. cluster2::> snapmirror update -destination-path svm_dst1:smv_dst1 Operation is queued: snapmirror update of destination "svm_dst1:smv_dst1". cluster2::> snapshot show -vserver svm_dst1 -volume smv_dst1 ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- svm_dst1 smv_dst1 snap_src1 160KB 0% 14% daily.2014-11-08_0010 284KB 0% 22% weekly.2014-11-23_0015 352KB 0% 26% weekly.2014-11-30_0015 272KB 0% 22% daily.2014-12-03_0010 220KB 0% 18% daily.2014-12-04_0010 112KB 0% 10% hourly.2014-12-04_1205 88KB 0% 8% hourly.2014-12-04_1305 84KB 0% 8% hourly.2014-12-04_1405 84KB 0% 8% hourly.2014-12-04_1505 88KB 0% 8% hourly.2014-12-04_1605 184KB 0% 16% hourly.2015-07-17_0705 104KB 0% 10% label1.1 88KB 0% 8% label2.1 84KB 0% 8% snapmirror.03770f75-296f-11e4-8232-005056011732_2147484674.2015-07-17_074500 84KB 0% 8% snapmirror.03770f75-296f-11e4-8232-005056011732_2147484674.2015-07-17_080000 92KB 0% 9% ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- svm_dst1 smv_dst1 label1.one-more-snapshot 92KB 0% 9% some-other-snapshot 68KB 0% 6% snapmirror.03770f75-296f-11e4-8232-005056011732_2147484674.2015-07-17_080349 0B 0% 0% 19 entries were displayed. cluster2::> snapshot show -vserver svm_dst1 -volume vault ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- svm_dst1 vault snap_src1 160KB 0% 40% label1.1 124KB 0% 34% label2.1 124KB 0% 34% snapmirror.03770f75-296f-11e4-8232-005056011732_2147484674.2015-07-17_074500 92KB 0% 28% 4 entries were displayed. cluster2::> snapmirror update -destination-path svm_dst1:vault Operation is queued: snapmirror update of destination "svm_dst1:vault". cluster2::> snapshot show -vserver svm_dst1 -volume vault ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- svm_dst1 vault snap_src1 160KB 0% 40% label1.1 124KB 0% 34% label2.1 124KB 0% 34% label1.one-more-snapshot 124KB 0% 34% some-other-snapshot 124KB 0% 34% snapmirror.03770f75-296f-11e4-8232-005056011732_2147484674.2015-07-17_080349 84KB 0% 26% 6 entries were displayed. cluster2::> I did not show buf if I create snapshots without snapmirror label they are not trasnferred to vault (they of course are transferred to SnapMirror destination). ... View more

OK, I see the problem. Well, NetApp documentation for cDOT is extremely vague. Both 8.2 and 8.3 allow you to define snapshot policies with explicit snapmirror labels. OTOH both 8.2 and 8.3 state that Only these [sm_created] Snapshot copies are replicated from the mirror to the SnapVault backup. But then again - 8.3 defines three different types of snapmirror policies - async-mirror, mirror-vault and vault. The first two always include sm_created rule that cannot be removed; the latter does not have sm_created rule by default which makes me believe that in this case it is possible to transfer only named snapshots. Which of course requires as prerequisite that snapmirror labels are replicated from source to destination by SnapMirror (and NetApp is silent on this).   I think your olnly option is to test it 🙂 Use simulator if you can; otherwise speak with your reseller and ask them to setup demo environment so you could test it. It does not really take long. Do you have access to LoD (Lab on Demand) by any chance?   If you got any results I appreciate if you could post them. If I get time I may try to quick test it; I'll update it then. ... View more

You can reassign ownership directly from filer1, you do not really need extra reboot for it. ... View more