toasters

toasters@lists.teaparty.net

13520 discussions

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

Re: max aggr size of 16TB
by Bert Kiers 05 Aug '10

05 Aug '10

1 0

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

05 Aug '10

2 2

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

05 Aug '10

We are trying to use best practices for setting up a CF pair of FAS6040s on a VMWARE data network, but are having problems. Nothing on the data network can ping the netapp heads nor can the heads ping each other over the data network. The switch administrator has verified that the switch stack is configured correctly. He says the switch reports that the netapps have not negotiated LACP yet. I want to run by our netapp config commands to verify that I haven't missed any commands or done them in the wrong order. The switch is a stack of two units. One head is supposed to favor one unit and the other head is supposed to favor the other unit. Here are the rc commands. vif create lacp vifb -b ip e0b e6b vif create lacp 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 On the other head I have this: vif create lacp vifb -b ip e0b e6b vif create lacp 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 We are running ONTAP 7.3.2. Does this look correct? ifconfig -a shows that all the physical interfaces have negotiated auto-1000t-fd-up full duplex ping 192.168.15.8 (from 192.168.15.6) fails and vice versa. To troubleshoot this, I think I will delete all the vifs, create vifc again, and put the VLANs on it and put the IPs on vifc-201 and vifc-202 and see what that gets me. Steve Losen scl(a)virginia.edu phone: 434-924-0640 University of Virginia ITC Unix Support

4 4

Re: Having trouble with VIFs and VLANs
by chaim rieger 05 Aug '10

05 Aug '10

Anybody else getting these spam messages ? Or is it just me

1 0

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