toasters

toasters@lists.teaparty.net

3 participants
13514 discussions

df -s value
by steve klise 14 Apr '10

14 Apr '10

Maybe I am missing something here: FAS6040 DOT 7.3.1.1 FC 500GB LUN 0 fractional reserve thin provisioned running dedupe (love it) I think there is a bug maybe in my version of DOT. I ran df-s on a volume, and this is what I am seeing. /vol/netapp_vol_vmware_DMZ_01/ 79484444 74719212 48% Should it be around 94% ? Here is the image from DFM (3.8) http://old.nabble.com/file/p28236746/25236%255B1%255D.gif -- View this message in context: http://old.nabble.com/df--s-value-tp28236746p28236746.html Sent from the Network Appliance - Toasters mailing list archive at Nabble.com.

3 3

Odd message on one VIF
by Page, Jeremy 14 Apr '10

14 Apr '10

I ran into an odd problem this week where CIFS would not let me delete a share and would not terminate. Eventually it got to the point where I just failed over to resolve the issue (which worked) but when the 2nd controller came back up I saw this in the logs: Tue Apr 13 23:53:26 EDT [gvr-pvif.setMediaFail: vif: unable to set media type on link e2a for tgif (error 22) Tue Apr 13 23:53:26 EDT [gvr-pvif.setMediaFail: vif: unable to set media type on link e2a for tgif (error 22) Tue Apr 13 23:53:26 EDT [gvr-pvif.setMediaFail: vif: unable to set media type on link e2b for tgif (error 22) Tue Apr 13 23:53:26 EDT [gvr-net.ifconfig.mediatype: The mediatype specified for tgif in the /etc/rc file is not valid for this interface and will be ignored. Tue Apr 13 23:53:28 EDT [gvr-netif.linkUp: Ethernet e2a: Link up. Tue Apr 13 23:53:28 EDT [gvr-netif.linkUp: Ethernet e2b: Link up. Tue Apr 13 23:53:28 EDT [gvr-pvif.switchLink: tgif: switching to e2a Here is my rc file, am I missing something? tgif is a Ten Gig InterFace, should I not have a mediatype specified? We do not have TOE enabled and that is the only reference I could find so I stuck with auto: vif create multi lan0 -b ip e0a e0c vif create multi tgif e2b e2a ifconfig lan0 `hostname`-lan0 netmask 255.255.255.0 mediatype auto mtusize 1500 partner lan0 nfo route add default 10.28.17.1 1 ifconfig tgif `hostname`-tgif netmask 255.255.0.0 mediatype auto mtusize 9000 partner tgif nfo -wins Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.

2 1

sdf and GX/OT8CM
by Kennedy, Jeffrey 14 Apr '10

14 Apr '10

Anyone who is running GX or 8CM, what are you doing to handle the sdf v. df issue of nested mounts? For those who don't know sdf is 'spinnaker' df and is used to find out df info on a nested volume in the GX namespace. I assume it's similar in 8CM as well but have not yet seen it. In any case, my first thought was simply a wrapper to determine if the mount was on a gx system and then either call sdf if so or pass off to the OS df if not. But if there's a more elegant solution I'd like to know. Thanks. Jeff Kennedy Qualcomm, Incorporated QCT Engineering Compute 858-651-6592 "Charity is no part of the legislative duty of the government." --James Madison

1 0

What exactly does SnapDrive buy me?
by Page, Jeremy 10 Apr '10

10 Apr '10

It looks like we're getting funding for our DR project. The bare bones are using snapmirror to replicate an Oracle DB offsite alone with a few dozen front end/infrastructure VMs. Two of the items we've been quoted by our vendor are SnapDrive & SnapRestore. I can understand snaprestore but why would I need snapdrive at the DR site? I don't even use it at our primary site, the Oracle system is very static, we do not have the hardware capacity to run a cloned instance and I'm comfortable with scripting a snapshot. I tried reading NetApp's SnapDrive document <http://media.netapp.com/documents/snapdrive.pdf> and it looks like it will do every buzzword under the sun but I have no idea what it really gets me other than the ability to see/control snapshots from the server - which I don't want. In addition it breaks the KISS idea which is important, especially since this system will be in another geographical location and not have as many eyes on it as a live system would. Am I missing something? Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.

4 3

RE: vseries pros and cons?
by Page, Jeremy 07 Apr '10

07 Apr '10

Thanks all, are the sw licensing costs similar to the equivelant FAS heads? "Fox, Adam" <Adam.Fox(a)netapp.com> wrote: Pretty much as you think. V-Series work exactly like a FAS system except there are other disks on the back-end. The only difference you will notice is that aggregates created on 3rd party disks will not have any RAID turned on from the filer side as we will rely on the back-end array to handle disk failures. In theory, the V-Series should never see a drive go away. The LUNs provisioned to the V-Series look like disks to the controller. Starting in 7.3, you can also hook up NetApp shelves at the same time. But all of the software features work just like a FAS. Once you create the aggregates, it looks, feels, and acts just like a FAS. -- Adam Fox Systems Engineer adamfox(a)netapp.com From: Page, Jeremy [mailto:jeremy.page@gilbarco.com] Sent: Tuesday, April 06, 2010 3:59 PM To: toasters(a)mathworks.com Subject: vseries pros and cons? What do I loose if I put a NetApp 3140 gateway infront of an old DS4500 instead of getting a nice shiney 2040? (other than the hardware differences in the controllers that is). Are there limitations on what you can do with a v series box? Do you just zone LUNs to the v system and it formats them with WAFL? Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment. Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.

3 2

vseries pros and cons?
by Page, Jeremy 06 Apr '10

06 Apr '10

What do I loose if I put a NetApp 3140 gateway infront of an old DS4500 instead of getting a nice shiney 2040? (other than the hardware differences in the controllers that is). Are there limitations on what you can do with a v series box? Do you just zone LUNs to the v system and it formats them with WAFL? Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.

2 1

RE: routing issue with 2 vifs on same subnet?
by Webster, Stetson 03 Apr '10

03 Apr '10

I forgot about this new feature until you mentioned it. Is this what you mean?: CIFS, NFS and iSCSI on a per-interface basis: https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb43722 Stetson Webster Professional Services Consultant Virtualization and Consolidation NCIE-SAN, NCIE-B&R, SCSN-E, VCP NetApp 919.250.0052 Direct Phone stetson(a)netapp.com Learn more: http://www.imaginevirtuallyanything.com -----Original Message----- From: Maxwell Reid [mailto:slinkywizard@integra.net] Sent: Saturday, April 03, 2010 1:18 AM To: Webster, Stetson Cc: tmac; Romeo Theriault; Holland, William L; Funke, Stefan; toasters(a)mathworks.com Subject: Re: routing issue with 2 vifs on same subnet? Request For Enhancement: Cisco routers have the ability to specify "source interface" for stuff like SNMP polling responses, traps, CDP etc. and routing protocol announcements. I think if you could do this for a filer, for management protocols and even particular mounts (all lockd, quotad, mount etc. responses for export X go out interface Y for netgroup Q. ) This would allow the admins to work around this problem when it crops up. I obviously don't see this asymmetric problem with the actual NFS traffic, but sometimes the supporting protocols like mountd and lockd get confused. Yes, I understand that it shouldn't be an issue because the RPC Layer doesn't really need to care about the IP addresses, but if you're in a shop that runs host based firewalls this leads to interesting and subtle breakage. All network setups aren't going to be flat, and fast path routing mechanisms do weird things with gateway redundancy protocols like HSRP. Mounting things over routed links is a perfectly legitimate activity and in fact are a good idea until we complete the transition to IPv6 where we can run things on huge flat networks without worrying about broadcast storms and the like. Besides, it's been a long time since routers were software boxes that added anything resembling significant latency or overhead. ~Max On Apr 1, 2010, at 7:28 AM, Webster, Stetson wrote: > The easiest solution (if possible): > > 1. Don't have all these subnets routable to and from each other; > isolate them. Best practices recommend that they do not route. > 2. If you need bandwidth across separate physical NICs, put them into a > large multimode VIF and then use VLAN tagging to separate the subnets. > > The issue at hand is called "assymmetric routing" (Google it). I > actually didn't realize there was a name for it until a couple years ago > ;-) When you Google it, the write-ups are pretty interesting readings. > It has its place, but I don't think this is not one of them. > > Good luck. > > > Stetson Webster > Professional Services Consultant > Virtualization and Consolidation > NCIE-SAN, NCIE-B&R, SCSN-E, VCP > > NetApp > 919.250.0052 Direct Phone > stetson(a)netapp.com > Learn more: http://www.imaginevirtuallyanything.com > > > > -----Original Message----- > From: tmac [mailto:tmacmd@gmail.com] > Sent: Thursday, April 01, 2010 8:28 AM > To: Romeo Theriault > Cc: Holland, William L; Funke, Stefan; toasters(a)mathworks.com > Subject: Re: routing issue with 2 vifs on same subnet? > > I suspect if: > > you turn ip.fastpath (back) on and you clear the default route, you > may likely be OK. > > The filer should only need the default route for its' own services > like sending autosupport > and if the mail server is on the same subnet, then the default route > is really not needed. > > When clients come in to a particular interface, ip.fastpath should > allow the request to go back out the same way they came in. > > might be worth a try to see if that in fact does it. > --tmac > Tim McCarthy > Principal Consultant > > RedHat Certified Engineer > 804006984323821 (RHEL4) > 805007643429572 (RHEL5) > > > > On Thu, Apr 1, 2010 at 8:11 AM, Romeo Theriault > <romeotheriault(a)gmail.com> wrote: >> On Thu, Apr 1, 2010 at 8:22 PM, tmac <tmacmd(a)gmail.com> wrote: >>> >>> just for kicks, >>> have your tried: >>> >>> route -f >>> >>> on your filer? if sa default route is set up, it may be the culprit. >>> you may not need the default route on the filer if all you services >>> are on the same subnet. >> >> Nope, haven't tried this. Since we have some clients that connect to > the >> filers from other subnets I'm not sure that this would be a good idea > for >> us. >> >> -- >> Romeo Theriault >> >

1 0

Re: Netapp virtual storage console for VMWare vSphere
by steve klise 02 Apr '10

02 Apr '10

Here is the fix or issue. We upgraded from 3.5 to 4.0. Alua is now supported. changed the IGroup type on the filer per link below put ESX host into maint mode I ran the ESX 5_1 ESX utility rebooted ran the config_mpath per ALUA article here http://blogs.netapp.com/storage_nuts_n_bolts/ rebooted BOOM, done, fixed; all green took out of maint mode Thanks to Support, they pushed me in the correct direction. Thanks to Nick Triantos article. Barlow, Richard wrote: > > Permissions problem possibly? Anything wonky in the logs on the esx > servers themselves? > > Thumb typed on my iPhone > > On Mar 30, 2010, at 9:02 PM, "steve klise" <klises(a)caminomedical.org> > wrote: > >> >> That is what I am doing. I am choosing "set recomended values". It >> runs, I >> click on UPDATE, and it does not change from red to green. >> >> Webster, Stetson wrote: >>> >>> The that part of the VSC data is not dynamic. You have to perform an >>> "update". >>> >>> >>> >>> Stetson Webster >>> Professional Services Consultant >>> Virtualization and Consolidation >>> NCIE-SAN, NCIE-B&R, SCSN-E, VCP >>> >>> NetApp >>> 919.250.0052 Direct Phone >>> stetson(a)netapp.com >>> Learn more: http://www.imaginevirtuallyanything.com >>> >>> >>> >>> -----Original Message----- >>> From: steve klise [mailto:klises@caminomedical.org] >>> Sent: Tuesday, March 30, 2010 7:30 PM >>> To: toasters(a)mathworks.com >>> Subject: Netapp virtual storage console for VMWare vSphere >>> >>> >>> Running Ontap 7.3.1.1 6040 HA >>> ESX 4.0.0.208167 running on DL380 and BL460's >>> Fiber Channel connectivity >>> I have the console installed in our VIC with the new Netapp snapin >>> and I >>> am >>> able to see the storage and successfully sees all the LUNS. >>> >>> I am having a problem trying to remediate my ESX hosts that are >>> having >>> the >>> typical MPIO issue. i have installed the VMWare ESX agent and it >>> installs. >>> I am still having an issue where the NVSC (netapp virtual storage >>> console) >>> is not remediating the MPIO issue, which is what I would prefer to do >>> then >>> SSH to each ESX host, install, reboot, etc. Call me lazy.. >>> >>> I have tried from different Windows machines, even on the VIC Console >>> where >>> the app (NVSC) is installed. It says performing tasks, then just >>> stops. >>> I >>> do an update, same thing. The MPIO icon never changes to green from >>> red. >>> >>> I have tried different ESX servers, same steps as above, same result. >>> MPIO >>> stays red. >>> >>> Has anyone come acrorss this? >>> -- >>> View this message in context: >>> http://old.nabble.com/Netapp-virtual-storage-console-for-VMWare-vSphere- >>> tp28089855p28089855.html >>> Sent from the Network Appliance - Toasters mailing list archive at >>> Nabble.com. >>> >>> >>> >>> >> >> -- >> View this message in context: >> http://old.nabble.com/Netapp-virtual-storage-console-for-VMWare-vSphere-tp2… >> Sent from the Network Appliance - Toasters mailing list archive at >> Nabble.com >> . >> > > :-):-):-):-):-):-):-) -- View this message in context: http://old.nabble.com/Netapp-virtual-storage-console-for-VMWare-vSphere-tp2… Sent from the Network Appliance - Toasters mailing list archive at Nabble.com.

1 0

Re: routing issue with 2 vifs on same subnet?
by Romeo Theriault 01 Apr '10

01 Apr '10

Here is a link to a tcpdump of my desktop machine trying to tcp mount a nfs export. http://romeodesktop.unet.maine.edu/desktop_mount_tcp_nfs.pcap In this tcpdump, I try to mount the volume like so: mount -o proto=tcp na2-vif2:/vol/vol0 /mnt/filer # na2-vif2 has an ip address of 10.10.2.12 and the vif1 has an ip address of 10.10.2.10 and as the tcpdump shows the filer responds to the initial getport calls from vif1. It eventually seems to respond out of vif2 and then things proceed to mount up after 30 seconds or so. On Fri, Apr 2, 2010 at 12:05 AM, Steve Francis <sfrancis(a)logicmonitor.com>wrote: > Huh - well that seems to indicate something else odd in the network setup. > Does a tcpdump from the host trying to mount the volume show the > return TCP packet being sourced with the incorrect IP? Or is it not > making back to the host if it exits out the "wrong" vif? > > > > On Thu, Apr 1, 2010 at 7:59 AM, Romeo Theriault > <romeotheriault(a)gmail.com> wrote: > > I get the same behavior regardless of if I try to mount with udp or tcp. > > > > On Thu, Apr 1, 2010 at 11:53 PM, Steve Francis < > sfrancis(a)logicmonitor.com> > > wrote: > >> > >> You could also switch to TCP mounts, instead of UDP (which I'm just > >> assuming you are currently using.) > >> Fastpath should be the answer, but with fastpath off, UDP packets that > >> were sent to VIF1, that are replied to by VIF2 (due to the filers > >> route table), will have a source address of VIF2 (and hence be dropped > >> by the mounting system.) TCP packets will be source with the IP > >> address of the destination interface on the filer, regardless of the > >> egress interface. > >> > >> So switching to TCP mounts will make your current config work rapidly, > >> but not necessarily with the transit paths as you want. > >> > >> (The above is characteristic of UDP - not just NetApps.) > > > -- Romeo Theriault System Administrator Information Technology Services

2 2

Re: routing issue with 2 vifs on same subnet?
by Romeo Theriault 01 Apr '10

01 Apr '10

I get the same behavior regardless of if I try to mount with udp or tcp. On Thu, Apr 1, 2010 at 11:53 PM, Steve Francis <sfrancis(a)logicmonitor.com>wrote: > You could also switch to TCP mounts, instead of UDP (which I'm just > assuming you are currently using.) > Fastpath should be the answer, but with fastpath off, UDP packets that > were sent to VIF1, that are replied to by VIF2 (due to the filers > route table), will have a source address of VIF2 (and hence be dropped > by the mounting system.) TCP packets will be source with the IP > address of the destination interface on the filer, regardless of the > egress interface. > > So switching to TCP mounts will make your current config work rapidly, > but not necessarily with the transit paths as you want. > > (The above is characteristic of UDP - not just NetApps.) >

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