toasters

toasters@lists.teaparty.net

13531 discussions

AW: VSCAN messages
by Robert.Reber＠stadt.nuernberg.de 15 Jan '09

15 Jan '09

Yes, it´s 250419. The problem still appears (currently using ONTAP 7.2.5.1) though. -----Ursprüngliche Nachricht----- Von: Eugene Vilensky [mailto:evilensky@gmail.com] Gesendet: Mittwoch, 14. Januar 2009 15:23 An: Reber, Robert Cc: toasters(a)mathworks.com Betreff: Re: VSCAN messages On Wed, Jan 14, 2009 at 2:05 AM, <Robert.Reber(a)stadt.nuernberg.de> wrote: > Yes, this is a known problem which should have been fixed in 7.2.3 but > apparently isn´t - the workaround is Hi, Is there a bug ID on this?

2 1

RE: SMVI - Limitations?
by Fox, Adam 15 Jan '09

15 Jan '09

I have to admit, I am not an SMVI expert, but I do know a thing or three about WAFL so I was speaking specifically about how snapshots and SnapRestore work at the ONTAP/WAFL level. As far as dedup (SIS), I'm not sure if I understand how/if it would "interfere" with a SnapRestore. In the case of a volume-level SnapRestore, the volume reverts back to the way it looked at the time of the snapshot used for the SnapRestore, and dedup would be no different there since the block pointers as well as the fingerprint file would be a part of the SnapRestore. I've actually never tried to figure out how it would work with a single-file SnapRestore. The good news is that with the release of the 7.3 simulator, which supports dedup, anyone can try it in their lab without touching their production stuff (on a smaller scale, of course). At most, you might have to re-run a full scan, but I'm honestly not sure. -- Adam Fox Systems Engineer adamfox(a)netapp.com -----Original Message----- From: Kumar, Rahul [mailto:kumarrahul@siemens.com] Sent: Wednesday, January 14, 2009 12:09 PM To: Fox, Adam; Sto Rage(c) ; toasters(a)mathworks.com; Darren.Sykes(a)csr.com Subject: RE: SMVI - Limitations? Adam So in theory, the snaprestore via smvi does actually do an individual file restores (talking about the a single vm restore) though there may be 100 of vms on the volume. So that does mean that we need to dedicate/separate volumes according to the usage etc. Also does SIS interfere when vm snaprestores are done by any chance ? Thanks for making the issue clear.. I am not in grip of the scenario and possible workarounds or new processes to b e followed Rahul -----Original Message----- From: Fox, Adam [mailto:Adam.Fox@netapp.com] Sent: Wednesday, January 14, 2009 9:51 PM To: Kumar, Rahul; Sto Rage(c) ; toasters(a)mathworks.com; Darren.Sykes(a)csr.com Subject: RE: SMVI - Limitations? WAFL Snapshots are always at the volume level. If you use the snap restore software on the controller, you can restore either the entire volume or an individual file level. Hope this helps. -- Adam Fox Systems Engineer adamfox(a)netapp.com -----Original Message----- From: Kumar, Rahul [mailto:kumarrahul@siemens.com] Sent: Wednesday, January 14, 2009 5:07 AM To: Sto Rage(c) ; toasters(a)mathworks.com; Darren.Sykes(a)csr.com; Fox, Adam Subject: RE: SMVI - Limitations? Hi Toasters A general scene and a question related to it. We have over 5TB of NFS datastore spread across various qtrees. We were evaluating SMVI and came to know that it also requires snaprestore to restore the VM's Now my question is that if e.g there was a qtree with say 50 vms on it and we'd like to snapshot only a few of them. Will this work ? When a snap is created on the filer it will capture all the VM's thus eating up valuable disk space from the snapreserve as time goes by. Next when we do a restore of the individual machine, it does a snap restore, however I am not sure if this only restores the individual machine or the entire stuff Any insight/help into this will be helpful Thanks Rahul -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Sto Rage(c) Sent: Saturday, January 10, 2009 4:52 AM To: toasters(a)mathworks.com Subject: Re: SMVI - Limitations? On Fri, Jan 9, 2009 at 12:19 AM, Darren Sykes <Darren.Sykes(a)csr.com> wrote: > You can tell SMVI (v1.1) not to perform OS level disk quiecing on those > machines if that's any use to you? > You'll then get a completely transparent Netapp level snapshot and won't > interfere with the VM itself. > > Darren It is SMVI v1.01 BTW, not 1.1 Not sure I understand this correctly, but if you are bypassing OS disk quiesce (VMWare snapshot) and doing transparent NetApp level snapshot, then why do you even need SMVI installed? Can't we just do the regular filer level snap schedule? We just upgraded to 1.01 and noticed the checkbox and were wondering about its potential use. Any ideas? thanks -G

3 2

RE: SMVI - Limitations?
by Fox, Adam 14 Jan '09

14 Jan '09

WAFL Snapshots are always at the volume level. If you use the snap restore software on the controller, you can restore either the entire volume or an individual file level. Hope this helps. -- Adam Fox Systems Engineer adamfox(a)netapp.com -----Original Message----- From: Kumar, Rahul [mailto:kumarrahul@siemens.com] Sent: Wednesday, January 14, 2009 5:07 AM To: Sto Rage(c) ; toasters(a)mathworks.com; Darren.Sykes(a)csr.com; Fox, Adam Subject: RE: SMVI - Limitations? Hi Toasters A general scene and a question related to it. We have over 5TB of NFS datastore spread across various qtrees. We were evaluating SMVI and came to know that it also requires snaprestore to restore the VM's Now my question is that if e.g there was a qtree with say 50 vms on it and we'd like to snapshot only a few of them. Will this work ? When a snap is created on the filer it will capture all the VM's thus eating up valuable disk space from the snapreserve as time goes by. Next when we do a restore of the individual machine, it does a snap restore, however I am not sure if this only restores the individual machine or the entire stuff Any insight/help into this will be helpful Thanks Rahul -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Sto Rage(c) Sent: Saturday, January 10, 2009 4:52 AM To: toasters(a)mathworks.com Subject: Re: SMVI - Limitations? On Fri, Jan 9, 2009 at 12:19 AM, Darren Sykes <Darren.Sykes(a)csr.com> wrote: > You can tell SMVI (v1.1) not to perform OS level disk quiecing on those > machines if that's any use to you? > You'll then get a completely transparent Netapp level snapshot and won't > interfere with the VM itself. > > Darren It is SMVI v1.01 BTW, not 1.1 Not sure I understand this correctly, but if you are bypassing OS disk quiesce (VMWare snapshot) and doing transparent NetApp level snapshot, then why do you even need SMVI installed? Can't we just do the regular filer level snap schedule? We just upgraded to 1.01 and noticed the checkbox and were wondering about its potential use. Any ideas? thanks -G

1 0

panics with 7.2.6.1
by Peter D. Gray 14 Jan '09

14 Jan '09

Just reverted all our filers to 7.2.5.1 after we had 7 panics in one day on 7.2.6.1 (6 on a 270A and 1 on a 3170A) We had been on 7.2.6.1 for 2 days but today was the first work day. Looks like a problems in the quota handling. Mon Jan 12 14:48:38 EST [naga: sk.panic:ALERT]: replayed event: Panic String: ../common/wafl/quotas/quota.c:1684: Assertion failure. in process wafl_lopri on release NetApp Release 7.2.6.1 Mon Jan 12 14:48:38 EST [naga: sk.panic:ALERT]: replayed event: Panic String: ../common/wafl/quotas/quota.c:1684: Assertion failure. in process wafl_lopri on release NetApp Release 7.2.6.1 Mon Jan 12 15:03:59 EST [naga: mgr.stack.string:notice]: Panic string: ../common/wafl/quotas/quota.c:1684: Assertion failure. in process wafl_lopri on release NetApp Release 7.2.6.1 Mon Jan 12 15:03:59 EST [naga: mgr.stack.string:notice]: Panic string: ../common/wafl/quotas/quota.c:1684: Assertion failure. in process wafl_lopri on release NetApp Release 7.2.6.1 Mon Jan 12 15:03:59 EST [naga: mgr.stack.at:notice]: Panic occurred at: Mon Jan 12 14:48:38 2009 Mon Jan 12 15:03:59 EST [naga: mgr.stack.at:notice]: Panic occurred at: Mon Jan 12 14:48:38 2009 Mon Jan 12 15:03:59 EST [naga: mgr.stack.proc:notice]: Panic in process: wafl_lopri Mon Jan 12 15:03:59 EST [naga: mgr.stack.proc:notice]: Panic in process: wafl_lopri Mon Jan 12 15:03:59 EST [naga: mgr.stack.framename:notice]: Stack frame 0: sk_vpanic(0xd84ccc) + 0x0 Mon Jan 12 15:03:59 EST [naga: mgr.stack.framename:notice]: Stack frame 0: sk_vpanic(0xd84ccc) + 0x0 Anyone else seen this? Regards, pdg -- See mail headers for contact information.

5 8

RE: SMVI - Limitations?
by Darren Sykes 14 Jan '09

14 Jan '09

SMVI uses snapshot 'normal' snapshot functionality of the filer so the granularity is constrained by that. At the current time, you cannot snapshot a file of files within a volume/qtree so in your scenario, you'd consume more than the necessary amount of storage space in creating a snapshot. To get around that you could either: 1) Reorganise your Datastores (perhaps using Storage VMotion) so that VMs with common snapshot/backup requirements live on the same Datastore 2) Hope that Netapp release additional functionality in OnTAP (and corresponding features in SMVI) so that you can snapshot individual files. The only other thing to note is that SMVI does allow you select a subset of VM's on a datastore for backup. The effect this has is that SMVI doesn't waste time quiecing the VM's that you haven't included in the backup job. Darren -----Original Message----- From: Kumar, Rahul [mailto:kumarrahul@siemens.com] Sent: 14 January 2009 10:07 To: Sto Rage(c) ; toasters(a)mathworks.com; Darren Sykes; Adam.Fox(a)netapp.com Subject: RE: SMVI - Limitations? Hi Toasters A general scene and a question related to it. We have over 5TB of NFS datastore spread across various qtrees. We were evaluating SMVI and came to know that it also requires snaprestore to restore the VM's Now my question is that if e.g there was a qtree with say 50 vms on it and we'd like to snapshot only a few of them. Will this work ? When a snap is created on the filer it will capture all the VM's thus eating up valuable disk space from the snapreserve as time goes by. Next when we do a restore of the individual machine, it does a snap restore, however I am not sure if this only restores the individual machine or the entire stuff Any insight/help into this will be helpful Thanks Rahul -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Sto Rage(c) Sent: Saturday, January 10, 2009 4:52 AM To: toasters(a)mathworks.com Subject: Re: SMVI - Limitations? On Fri, Jan 9, 2009 at 12:19 AM, Darren Sykes <Darren.Sykes(a)csr.com> wrote: > You can tell SMVI (v1.1) not to perform OS level disk quiecing on those > machines if that's any use to you? > You'll then get a completely transparent Netapp level snapshot and won't > interfere with the VM itself. > > Darren It is SMVI v1.01 BTW, not 1.1 Not sure I understand this correctly, but if you are bypassing OS disk quiesce (VMWare snapshot) and doing transparent NetApp level snapshot, then why do you even need SMVI installed? Can't we just do the regular filer level snap schedule? We just upgraded to 1.01 and noticed the checkbox and were wondering about its potential use. Any ideas? thanks -G To report this email as spam click https://www.mailcontrol.com/sr/vp!1JnK84mHTndxI!oX7Ug+zP6wRoWawawux2rV25 mcJ4jEHfEKQsBBo5y31p0!L1slOaqyO5jedye7!a4hOmw== .

1 0

AW: VSCAN messages
by Robert.Reber＠stadt.nuernberg.de 14 Jan '09

14 Jan '09

Yes, this is a known problem which should have been fixed in 7.2.3 but apparently isn´t - the workaround is priv set diag ; setflag smb_vscan_delay_close_resp 1 ; priv set;vscan off ; vscan on Try that - if it works, then put it in the /etc/rc of your filer(s) - works fine for us - I tried it without the workaround after the last few ONTAP-Updates since it should be fixed, but always had to put it back into /etc/rc... Greetz, Rob -----Ursprüngliche Nachricht----- Von: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com]Im Auftrag von JamieB Gesendet: Dienstag, 13. Januar 2009 23:57 An: toasters(a)mathworks.com Betreff: VSCAN messages NetApp FAS270 FAS3020 and FAS3140A DOT ver 7.2.3 McAfee Vscan for NetApp Filers v7.1 I am seeing a lot of the following messages in /etc/messages ERROR: [vscan.virus.detected:error]: CIFS: Virus Detected - <file path> in share [Share name not available] accessed by client **unknown** (**unknown**) running as user **unknown** is infected. The filer received status message Error 5 ...Continuing and error code [5] from vscan (anti-virus) server **unknown**. The service account of the Vscan application is in the local admin group of the filer. NetApp has recommended upgrading to DOT 7.3 but I am somewhat hesitant since all of filers are using quotas and usermap.cfgs - have seen a few emails concerning "panic" problems. Has anyone else seen similar results with their Vscan application on the filers? Regards,

1 0

VSCAN messages
by JamieB 13 Jan '09

13 Jan '09

NetApp FAS270 FAS3020 and FAS3140A DOT ver 7.2.3 McAfee Vscan for NetApp Filers v7.1 I am seeing a lot of the following messages in /etc/messages ERROR: [vscan.virus.detected:error]: CIFS: Virus Detected - <file path> in share [Share name not available] accessed by client **unknown** (**unknown**) running as user **unknown** is infected. The filer received status message Error 5 ...Continuing and error code [5] from vscan (anti-virus) server **unknown**. The service account of the Vscan application is in the local admin group of the filer. NetApp has recommended upgrading to DOT 7.3 but I am somewhat hesitant since all of filers are using quotas and usermap.cfgs - have seen a few emails concerning "panic" problems. Has anyone else seen similar results with their Vscan application on the filers? Regards,

1 0

changing/setting flow control
by George Kahler 13 Jan '09

13 Jan '09

Hi guys, I would like to change/set one of the NICs on a FAS3040 to enable flow control after my Network Operations guys turn-on flow control on their switch port. Can I just "filer> ifconfig e0a flowcontrol full" while the filer is serving data or do I need to 'down/up' the interface ? The protocols on the filer is all nfs and some iSCSI. Thanks, George

7 8

Snapmanager for Virtual Infrastructure, RDM to VMFS/NFS Migrations...
by Ken Williams 12 Jan '09

12 Jan '09

Has anyone migrated from RDM to a standard VMFS or NFS Datastore? I was hoping Svmotion would handle the move without powering down the virtual machine but it looks like that may not be supported. I'd like to accomplish this without outages (or extremely limited downtime for the hosts), any ideas? __________________________________________________________ Ken Williams Storage Administrator, Business Technology Operations Sacramento Municipal Utility District E-Mail: kwillia(a)smud.org Phone: (916) 732-6744 Cell: (916) 240-4213

5 9

RE: SMVI - Limitations?
by Ken Williams 09 Jan '09

09 Jan '09

Our databases are on RDMs, actually all our VMs are on RDMs. I'm working on migrating to NFS/IP storage and SMVI is part of that design. -----Original Message----- From: Matt Hallmark [mailto:matt@cosmictoaster.com] Sent: Thursday, January 08, 2009 4:00 PM To: Ken Williams Cc: Bill Holland; toasters(a)mathworks.com Subject: Re: SMVI - Limitations? Are your databases on VMDK's, RDM's or are you using an iscsi initiator in the VM? Thx, Matt On Jan 8, 2009, at 3:50 PM, Ken Williams wrote: > In our environment if we perform a VMWare snapshot of a SQL or Oracle > database it will crash. So we've actually set policy so those do not > get snapshots. > > From: Bill Holland [mailto:hollandwl@gmail.com] > Sent: Thursday, January 08, 2009 3:43 PM > To: Ken Williams; toasters(a)mathworks.com > Subject: Re: SMVI - Limitations? > > I've been experimenting with SMVI some and it appears to work hand- > in-hand with vCenter. Essentially, it takes a VMware snapshot, > followed by a filer snapshot (and snapmirror update if you tell it > to), then deletes the VMware snapshot. The VMware snapshot before the > filer snapshot ensures the volumes are quiesced and buffers flushed > before the filer snapshot to ensure consistency. > > I think you'll still have to place your databases in hot backup mode > before taking a snapshot. > > Currently our Oracle and SQL data, index, redo, and archives exist on > iSCSI LUNs with SnapDrive for Windows. As we progress with VMware, we > will likely place our OS and Applications either on NFS volumes or > VMFS formatted iSCSI LUNs. We will then continue to use SnapDrive for > Windows to manage our database LUNs as this is something we are > familiar with and are very comfortable with our current recovery model > in regards to the databases themselves. Plus we often wish to take > snaphots on them several times a day during our production cycles. > Simply go into hot backup mode, take snapshot of all but archive > volumes, exit hot backup mode, snapshot archive volume. It happens so > quickly our users never notice it and we have recovery points at key > times during our production cycle should something go wrong during one > of the daily operations. This is for Oracle. Our SQL databases are > small and not mission critical so simply taking a filer snapshot and > letting SQL do its crash recovery if we restore a snapshot works fine. > ----- Original Message ----- > From: Ken Williams > To: toasters(a)mathworks.com > Sent: Thursday, January 08, 2009 2:41 PM > Subject: SMVI - Limitations? > > We're making the plunge to move to NFS and SMVI (from RDM backed luns > and homegrown snapshot management scripts). > > Does anyone know of any limitation to how many VMs can exist in a data > store that SMVI is snapping? Is there any impact when snapping virtual > machines (outside of SQL/Oracle VMs)? > > __________________________________________________________ > Ken Williams > Storage Administrator, Business Technology Operations Sacramento > Municipal Utility District > E-Mail: kwillia(a)smud.org > Phone: (916) 732-6744 > Cell: (916) 240-4213 >

1 0

Jump to page:

2026

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