toasters

toasters@lists.teaparty.net

13520 discussions

Re: The following prevents offline of volume: zapi snapshot list
by Fletcher Cocquyt 10 Feb '12

10 Feb '12

The snapshot process must have completed - I was able to offline by waiting a few minutes thanks Fletcher On Feb 10, 2012, at 2:31 PM, Parisi, Justin wrote: > Are you able to reboot the box? Because those will need to complete otherwise before it allows a vol offline. > > If you try to force the vol offline, it will hang. Reboot will clear this up and you should be able to offline the vols. > > From: toasters-bounces(a)teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Fletcher Cocquyt > Sent: Friday, February 10, 2012 4:57 PM > To: toasters(a)teaparty.net > Subject: The following prevents offline of volume: zapi snapshot list > > Hi > I'm attempting to offline all the volumes on this 64bit aggr so I can destroy and re-create as 32 bit (so 32->32 bit data motion is supported) > > I am encountering this error: > > The following prevents offline of volume vm2 > zapi snapshot list > zapi snapshot list > zapi snapshot list > > How do I clear it so I can proceed? > > thanks > > Fletcher > > > > > >

1 0

The following prevents offline of volume: zapi snapshot list
by Fletcher Cocquyt 10 Feb '12

10 Feb '12

Hi I'm attempting to offline all the volumes on this 64bit aggr so I can destroy and re-create as 32 bit (so 32->32 bit data motion is supported) I am encountering this error: The following prevents offline of volume vm2 zapi snapshot list zapi snapshot list zapi snapshot list How do I clear it so I can proceed? thanks Fletcher

1 0

dedup changed in 8.1?
by Fletcher Cocquyt 10 Feb '12

10 Feb '12

Last night (first since the upgrade from 7.3.5.1P2 to 8.1RC2) we experienced much higher load on our 3270 cluster and some VM timeouts coinciding with our dedup schedule (11pm -2am) Anyone heard if dedup changed in 8.1? I am disabling the regular dedup schedule until this is sorted out thanks Fletcher

5 5

nfsstats help
by Jeremy Page 09 Feb '12

09 Feb '12

How do I find out what's causing these messages and what the severity is? With large chunks taken out: Server rpc: TCP: calls badcalls nullrecv badlen xdrcall 72337 4294847830 0 0 4294847830 No of RAID errors propagated by WAFL = 2184604 It certainly looks bad but I am not sure if this is a big deal or not. I've been seeing some ugly latencies on my NFS traffic over the past day or so and I'm trying to determine what it could be. They are running in the 15-20 ms range (from stats show -i5 nfsv3) where normally it's under 5ms. 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.

1 0

Force 64bit aggr migration
by Fletcher Cocquyt 09 Feb '12

09 Feb '12

Anyone know if its possible to force the in place 32->64bit aggr non-disruptive migration without having to add disk? I'm running into a 8.1R2 data motion issue where NMC is refusing to migrate vFilers from the 32 bit source cluster to the 64bit destination. The destination aggrs are at or above 16Tb so they need to be 64 bit thanks Fletcher

4 4

Fas 3240 failover delay
by John Sfetsoris 09 Feb '12

09 Feb '12

Hello everybody I have a Fas3204 HA in two seperate chassis , dataontap version 8.02P3 7mode. Many NFS servers are connected to it via iscsi connections. NFS servers are VMware mashines . VMware version is VSPERE 5. There are 4-5 Vfilers running. When i force a failover from the one controler to other, the NFS clients have a delay about 30-40 seconds. Is this normal? Can i do something to investigate/tune the failover proccess? thnks in advance John

5 6

Re: NDU from 7.3.5.1P3 to 8.1RC2 supported?
by Fletcher Cocquyt 09 Feb '12

09 Feb '12

I found and corrected the typo in the rc file - now the check passes on the rc files, but not the running config. Is it safe/recommended to reissue the ifconfig na03-vif0-205 `hostname`-na03-vif0-205 netmask 255.255.255.192 partner na04-vif0-205 up to update the partner in the running config? Or is there a better method? thanks -- Fletcher On Jan 31, 2012, at 2:48 PM, Chris Muellner wrote: > Verify the RC files on both controllers. You can ignore the c0x interfaces, but the tool is saying you’ll have an issue with this VIF here: NO PARTNER FOR na04-vif0-205 (17.25.104.23) ON na04 in /etc/rc > > Make sure the ifconfig statement in both controllers RC files for that interface have the partner interface specified in the statement. > > From: toasters-bounces(a)teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Fletcher Cocquyt > Sent: Tuesday, January 31, 2012 1:01 PM > To: SW > Cc: toasters(a)teaparty.net > Subject: Re: NDU from 7.3.5.1P3 to 8.1RC2 supported? > > Thanks for the feedback Steve, > > I'm also running the netapp tool to check HA prior to failover: > Are these partner network errors valid? Someone in the community forums said they are bogus > > ./ha-config-check.cgi -s na03 na04 > == NetApp HA Configuration Checker v2.0.0 == > > > Checking ssh logins ... > > > Checking ssh logins ... > > OK > > Checking Data ONTAP versions... > > OK > > Checking licenses... > > OK > > Checking HA configuration identity... > > OK > > Checking cf status... > > OK > > Checking fcp cfmode settings... > > fcp: FCP is not licensed. > N/A > > Checking options... > > OK > > Checking network configuration... > > c0a (192.168.1.152) on na03 does not have a partner on na04 > c0b (192.168.2.173) on na03 does not have a partner on na04 > c0a (192.168.1.84) on na04 does not have a partner on na03 > c0b (192.168.2.95) on na04 does not have a partner on na03 > na04-vif0-205 (17.25.104.11) on na04 does not have a partner on na03 > > > > > Checking network config in /etc/rc > > NO PARTNER FOR na04-vif0-205 (17.25.104.23) ON na04 in /etc/rc > HA configuration issue(s) found above. Please correct them and rerun this script. > Done. > > -- > Fletcher > > > > > On Jan 31, 2012, at 10:29 AM, SW wrote: > > > Hi Fletcher, > > I only have a subset of answers relating to your Toasters inquiry, but I thought I’d share what I can... > > According to the upgrade guide for 8.1RC2 (attached to this e-mail), a NDU from 7.3.5.1P3 to 8.1RC2 is supported: > > > From page 15: > “Nondisruptive upgrades to releases in the Data ONTAP 8.1 7-Mode release family are supported > from the following releases: > • Any 8.0.x release > • 7.3.2 and later 7.3.x releases” > > Good luck! > Steve > <upgrade.pdf>

6 10

vfiler migrate: overview and thoughts
by Randy Rue 09 Feb '12

09 Feb '12

vfiler migrate: overview and thoughts When I first read there was a way to move a vFiler from one node of a NetApp cluster to another I was excited. I was imagining something akin to VMWare's vMotion, a transparent movement of services. Digging a little deeper showed that NetApp's "vfiler migrate" functionality isn't nearly as automagic as I'd hoped. Here are some observations. * Disk ownership of the resources must be software based whether your filer is using actual disks or array LUNs (on a vSeries filer like our 3170). We had some concerns that the feature might not work well with array LUNs but it appears that Data OnTap doesn't know any difference between an Array LUN and an actual disk in this context. * The vfiler migrate command effectively moves complete aggregates from one filer head to another. This means that all volumes on the aggregate(s) involved must be tied only to the vfiler being moved, with no LUNs, exports or shares presented from the context of the root filer or any other vFiler (in our environment we already had a standard of creating separate aggregates for each vFiler so this wasn't a problem). For example, after one failed attempt to migrate a filer, I had added a CIFS share to the root volume of the vFiler via the root filer, to gain access to the etc folder of the vFiler. I forgot to remove that share, and broke later migration attempts for a new reason. * We've tested the vfiler migrate command dozens of times now on three different vFilers, in preparation for the migration of a production vFiler later this week. Two of those vFilers have migrated flawlessly every time, and one seems to fail about 30% of the time for various reasons which we can sometimes identify and sometimes not. * Reasons for failure include: - A CIFS share from the root filer head to the vFiler's root volume. My bad. - Possible FC noise between the root filer and the SAN behind it. - Possible SCSI reservations issues between the root filer and the SAN. - Invalid credentials (fat-fingered a password, I think) for the "source" remote root filer. Oddly, the migrate command still stopped the vFiler, offlined its volumes and aggregates, and removed the vFiler from the source root filer before the process failed. - Poor alignment of the planets? Bad karma? * In general, it seems that the vfiler migrate just fails sometimes. In every failure, however, recovery has been straightforward. The "vfiler create <vFiler name> -r <path to vFiler root volume>" command recovers the vFiler every time, albeit without a proper network configuration. The vFiler comes back up but with its virtual NIC having no subnet mask or assignment to a physical interface. Makes sense, I guess, as the migrate command never got to the part where it normally asks what mask and interface to use. This needs to be reassigned, either from the CLI using ifconfig or the "manage vFiler" wizard in FilerView (note that this will also overwrite etc/exports with a default but will save a backup first). Given that there are arguably a slew more shops out there running HA VMWare clusters than there are running HA NetApp clusters, it's probably not fair to expect that vfiler migrate is going to be as slick or even as well understood/documented in the wild as vMotion. Also, inherent limitations in things like the CIFS protocol make it necessary that some services will have to be interrupted. But overall I'd claim that the feature is useful and even when it doesn't work as hoped recovery is straightforward and reliable. We're planning on proceeding with our production move later this week. Hope this helps anyone in the same situation, Randy

4 5

nfsiostat and client NFS connections
by Randy Rue 08 Feb '12

08 Feb '12

Hello All, Trying to troubleshoot performance problems on our v3170. This is not specifically a NetApp question but if nothing else, the tool I'm using appears to have been written by a NetApp engineer, does that count? Running nfsiostat on a handful of impacted clients on another network and uploading the results to a timestamped log file served on a web server so I can reach them. I have a script that parses those pages, takes the last timestamped entry from each file (one file for each client), and tallies up a) the average RTT time for all mounts to the vFiler and b) the worst single instance. Now that I have it all working, the numbers don't believe like I think they should. The clients are adding an entry to each file every minute. I can see that from the timestamps before each entry. But the numbers don't change. Or they change by a few hundredths of a ms. My gather script returns an average that varies only by .01ms or so, and my "worst" figure has been steady for an hour now. We're running nfsiostat with no arguments. Am I getting real time readings or some average? If average, since when? Is there a way to get real-time? Hope to hear from you, Randy Rue

9 16

Re: FlexShare
by Jack Lyons 08 Feb '12

08 Feb '12

I had an SE say the same thing and stayed away from it also for same reason - we have an older filer that gets pounded in evenings and was wondering if anyone had a big success story. Thanks Jack ------Original Message------ From: Scott Eno To: Jack Lyons Cc: toasters(a)teaparty.net Subject: Re: FlexShare Sent: Feb 8, 2012 9:06 AM Hi Jack, I have done some small testing with it, but I shied away from implementing it when a NetApp instructor said that to get the best results you have to apply it to ALL the volumes on the filer hosting the particular volume(s) you are looking to improve performance on. Not sure if that's true or not, but it was his suggestion. I figured if that were the case I would be spending a lot of time tweaking all volumes on a filer just to possibly squeeze a bit more out of one or two. --- Scott Eno (First time poster, long time reader) On Feb 8, 2012, at 7:20 AM, Jack Lyons <jack1729(a)gmail.com> wrote: > Has anyone used FlexShare and had extremely positive results. IT seems > that the improvement would be minor and misconfiguration could lead to > no improvement for intended volumes and degradation for others. From > reading, it seems that you need to assign priorities to each volume > otherwise the volumes in the default queue will experience degradation. > > Would anyone like to share details of how the implemented flexshare and > the impact it had on the performance issue they were working to resolve? > > Would also like to know if anyone has try to 'schedule flexshare' > settings using rsh or api e.g. we want to give higher priorities to > certain volumes from 6pm to 11pm nightly. > > Thanks > Jack > _______________________________________________ > Toasters mailing list > Toasters(a)teaparty.net > http://www.teaparty.net/mailman/listinfo/toasters Sent from my Verizon Wireless BlackBerry

2 1

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