toasters

toasters@lists.teaparty.net

3 participants
13514 discussions

Re: Snapmirror specific snapshot (only)
by Fox, Adam 26 Aug '10

26 Aug '10

VSM is designed differently from QSM and thus does not support -s. -- Adam Fox ------------------------ Typed with my thumbs on a very small keyboard. ----- Original Message ----- From: lists(a)up-south.com <lists(a)up-south.com> To: toasters(a)mathworks.com <toasters(a)mathworks.com> Sent: Wed Aug 25 22:19:07 2010 Subject: Snapmirror specific snapshot (only) I know qtrees can do this via -s -c Can a vol snapmirror be restricted to a single snapshot ? Or a regex based snapshot name ? Sent via BlackBerry by AT&T

2 1

Snapmirror specific snapshot (only)
by lists＠up-south.com 26 Aug '10

26 Aug '10

I know qtrees can do this via -s -c Can a vol snapmirror be restricted to a single snapshot ? Or a regex based snapshot name ? Sent via BlackBerry by AT&T

1 0

Moving disk shelves to new controller
by Steve Losen 25 Aug '10

25 Aug '10

Hello Toasters, We are going to move some disk shelf chains that contain aggregates to new heads. The old heads are a CF pair of FAS3050s running 7.3.1.1 and the new heads are a CF pair of FAS3170s running 7.3.2. We will not replace the existing root volumes on the 3170s. I am planning to shut everything down and reconnect the shelf chains. When I power everything back up, the new heads will boot and find a lot more disks. Will they recognize the aggregates? From the aggr man page it looks like the aggregates will be recognized as "foreign" and I will need to run "aggr online". The 3050 does not use software disk ownership, each head owns entire disk shelf chains. The 3170 uses software disk ownership. Any issues there? Do I need to disable disk.auto_assign on the 3170s beforehand and manually assign the disks to the correct heads? Then reboot? Instead I could connect each shelf chain to just the 3170 head that will own it, and boot the 3170s. They should find their new disks, take ownership, and see the new aggregates. Then I could shut down, connect the shelf chains to both heads, and boot back up. Seems easier, but will it work? Am I missing anything important? Steve Losen scl(a)virginia.edu phone: 434-924-0640 University of Virginia ITC Unix Support

2 2

Re: Moving disk shelves to new controller
by Steve Losen 24 Aug '10

24 Aug '10

Thanks to everyone who responded. It looks like I can do the following to move disk shelves from a FAS3050 CF pair to a FAS3170 CF pair. 1) Upgrade the FAS3050 pair to ONTAP 7.3.2, which is on the FAS3170s. 2) Run "options disk.auto_assign off" on FAS3170s (to be safe). 3) Shut down the FAS3050s and FAS3170s. 4) Connect each shelf chain from the FAS3050s to just one of the FAS3170 heads. 5) Boot FAS3170s into maintenance mode and run "disk assign all" to assign software disk ownership. (Why must this be done in maintenance mode? Because the disks are not spares? Because the FAS3050s do not use software disk ownership?) 6) Shut down FAS3170s and connect the shelf chains to both heads. 7) Boot FAS3170s normally. Should see foreign aggregates. Run "aggr online" to bring online. (I will not have any aggr or vol name conflicts.) Also run "options disk.auto_assign on". Steve Losen scl(a)virginia.edu phone: 434-924-0640 University of Virginia ITC Unix Support

1 0

VFiler Physical Disk Reserve
by Fred Grieco 10 Aug '10

10 Aug '10

What is the physical disk reserve on a V-Filer supposed to be? And is it tune-able? I have a v-filer setup and it looks like it's holding back 25% between the backend luns (on an IBM DS8300) and the front-side aggregates. This seems like a huge amount-- more than it would hold back for a physical disk and excessive in light of the existing physical protection on the DS8300. TIA, Fred

1 0

parts finder
by Nick Bernstein 10 Aug '10

10 Aug '10

Hi all, Could someone do me a favor and take a screenshot of a sysconfig with output showing an ethernet adaptor or FC adaptor line as well as the results of parts finder from the now site? I've had a couple not show up when doing it in class, and I'm assuming it's just a random anomaly and not a real issue with parts finder. Thanks in advance, Nick

2 1

Shrinking an aggregate via netboot ?
by Simon Vallet 09 Aug '10

09 Aug '10

Hi list, I currently have to address a quite interesting problem : long story short, we need to remove disks from the root (and only) aggregate of a 3020 cluster. Since this is not possible [1], and as we don't have other aggregates on this filer, do you think it would be feasible to : - copy the root volume on another filer ; - netboot a head ; - destroy the root aggregate ; - create another one, with the correct number of disk drives ; - copy the root volume back ? Yes, I did contact NetApp about the subject. Simon [1] https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb45864

2 2

Re: A couple of V-Series Questions
by Bob McKim 06 Aug '10

06 Aug '10

Matt, we can't retain vol0 for a couple of reasons - 1) The old heads are x86 (V3020) and new heads are x64 (N6040 / V3120), therefore the binaries are different. 2) NetApp ONTAP on old heads, IBM ONTAP on new ones. How about if I do a config dump and a config dump -v on the old heads and do a config restore on the new ones before swinging the aggrs? They are both running 7.2.6.1 (I had to downlevel the n6040 FROM 7.2.3 for snapmirror purposes). Bob McKim |------------> | From: | |------------> >----------------------------------------------------------------------------------------------------------------------------------------| |Matt Hallmark <matt(a)cosmictoaster.com> | >----------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >----------------------------------------------------------------------------------------------------------------------------------------| |Bob McKim/Omaha/IBM@IBMUS | >----------------------------------------------------------------------------------------------------------------------------------------| |------------> | Cc: | |------------> >----------------------------------------------------------------------------------------------------------------------------------------| |<toasters(a)mathworks.com> | >----------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >----------------------------------------------------------------------------------------------------------------------------------------| |08/05/2010 05:34 PM | >----------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >----------------------------------------------------------------------------------------------------------------------------------------| |Re: A couple of V-Series Questions | >----------------------------------------------------------------------------------------------------------------------------------------| For #1, you are creating a new aggr and migrating data. the aggregates on a V-Series are raid0 (aggr options aggrname to see it), so you can't fail a drive/lun per se. For #2, you are correct on most of the steps, but as you will be retaining your root volumes, there's no need to re-create shares or change dns etc. Procedurally it's: 1. Halt existing cluster and power off the nodes 2. Rack and cable the new cluster, power on the nodes and go into maintenance mode. 3. Verify that the ports you want to use are initiators and document the WWPN's (storage show adapter) 4. Update the zoning on the switches for the new initiator ports 5. On the back-end SAN, update your host profile to reflect the new WWPN's 6. From maint mode, reassign the LUNs from the old systemID to the new one, repeat for the other node 7. using aggr status from maint mode, validate that you can see your various aggrs and that you have one marked as a root aggr on each controller 8. halt both nodes and boot them up normally. 9. Upgrade ontap if you are changing CPU architectures. As a pre-step, you might want to validate that the version of OnTap that's on the CF of the new controllers is compatible w/ the version of ontap (raid labels etc). If the existing OS/raid labels etc in-use is 7.2.X, you will very likely want to upgrade to 7.3.X before doing the head swap, as the last V-Series I un-boxed last month was running 7.3.2GA. Matt Hallmark On Aug 5, 2010, at 2:44 PM, Bob McKim wrote: > 1) I have a customer who accidentally added a LUN to an existing aggr that was incorrectly sized. What is the correct procedure to replace that LUN with a correctly sized one? They can't resize the LUN on the existing array as it's out of space. Do I create a correct sized LUN on another array, add it as a spare and then do a disk fail against the wrong sized LUN? I've never tried this on a gateway. > > 2) Does anyone have some procedures for a headswap on a v-series/gfiler? There appears to be a "black hole" on the NOW site in regards to how-to upgrade a v-series/gfiler. > > Is it as simple as - > > > 1) Gather existing v-series head configuration > 2) Zone and LUN mask the new v-series head to the existing LUNs > 3) Perform a disk reassign ownership on an aggr by aggr basis > 4) Create new CIFS shares on new v-series head (only CIFS shares on existing v-series head) > 5) Remove old v-series head from DNS (or swap servers in DFS) > 6) Add new v-series head to DNS > 7) Verify client connectivity > > Thanks > > Bob McKim > > Although no hardware was injured in the creation of this note, a few billion electrons and photons were utilized against their will.

1 0

A couple of V-Series Questions
by Bob McKim 06 Aug '10

06 Aug '10

1) I have a customer who accidentally added a LUN to an existing aggr that was incorrectly sized. What is the correct procedure to replace that LUN with a correctly sized one? They can't resize the LUN on the existing array as it's out of space. Do I create a correct sized LUN on another array, add it as a spare and then do a disk fail against the wrong sized LUN? I've never tried this on a gateway. 2) Does anyone have some procedures for a headswap on a v-series/gfiler? There appears to be a "black hole" on the NOW site in regards to how-to upgrade a v-series/gfiler. Is it as simple as - 1) Gather existing v-series head configuration 2) Zone and LUN mask the new v-series head to the existing LUNs 3) Perform a disk reassign ownership on an aggr by aggr basis 4) Create new CIFS shares on new v-series head (only CIFS shares on existing v-series head) 5) Remove old v-series head from DNS (or swap servers in DFS) 6) Add new v-series head to DNS 7) Verify client connectivity Thanks Bob McKim Although no hardware was injured in the creation of this note, a few billion electrons and photons were utilized against their will.

2 2

Re: Having trouble with VIFs and VLANs
by Steve Losen 05 Aug '10

05 Aug '10

Thanks to everyone for all the helpful suggestions. Through experimentation we discovered that we cannot mix LACP and VLAN tagging. We don't know if it's the switch or ONTAP and we haven't seen any documentation or bug reports. The switch is a stack of two Nortel units. Didn't note the model, but each unit has 48 ports each 1Gbit. So we reconfigured the switch for "multi" trunking and VLAN tagging and all is working as expected: First head: vif create multi vifb -b ip e0b e6b vif create multi vifc -b ip e0c e6c vif create single vif0 vifb vifc # favor switch unit 1 vif favor vifb vlan create vif0 201 202 ifconfig vif0-201 192.168.5.6 netmask 255.255.255.0 partner vif0-201 ifconfig vif0-202 192.168.15.6 netmask 255.255.255.0 partner vif0-202 Second head: vif create multi vifb -b ip e0b e6b vif create multi vifc -b ip e0c e6c vif create single vif0 vifb vifc # favor switch unit 2 vif favor vifc vlan create vif0 201 202 ifconfig vif0-201 192.168.5.8 netmask 255.255.255.0 partner vif0-201 ifconfig vif0-202 192.168.15.8 netmask 255.255.255.0 partner vif0-202 Steve Losen scl(a)virginia.edu phone: 434-924-0640 University of Virginia ITC Unix Support

3 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters