toasters

toasters@lists.teaparty.net

2 participants
13529 discussions

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

RE: RE-export volume/qtree question
by Kevin M. Parker 08 Jan '09

08 Jan '09

Resend, sorry. Hey Folks, I've a volume export entry that look like such /vol/volume -sec=sys,rw, root=xyz The client mounts it at the qtree like such Filer:/vol/volume/qtree I need to re-export this at the qtree level such that client do NOT have the ability to write into the volume, only the qtree, so new/proposed export entry will look like /vol/volume/qtree sec=sys,rw,root=xyz Since clients already mount at qtree level, can't I just re-export at the qtree, remove the volume export and exportfs? Will this be any impact, or change to FSID? Cheers, Best regards, -/- Kevin Parker 919.521.8413 http://theparkerz.com <http://theparkerz.com/> Blackle.com <http://www.blackle.com/> - Saving energy one search at a time.

2 1

fakeroot on a mixed qtree not working properly.
by Page, Jeremy 06 Jan '09

06 Jan '09

The info below was sent to me by one of our engineers. I also tried switching the qtree to UNIX instead of mixed but it gives me an error "qtree update: qtree security style update: qtree: There are shares with connections on qtree" Any suggestions? Below is an example of fakeroot not working properly. First I present what should happen (this is on a local machine not using my network drive) kuebert@gsows-eng138:~/tmp$ mkdir foo kuebert@gsows-eng138:~/tmp$ ls -l total 4 drwxr-xr-x 2 kuebert kuebert 4096 2009-01-05 15:52 foo/ kuebert@gsows-eng138:~/tmp$ fakeroot chown root:root foo kuebert@gsows-eng138:~/tmp$ ls -l total 4 drwxr-xr-x 2 kuebert kuebert 4096 2009-01-05 15:52 foo/ kuebert@gsows-eng138:~/tmp$ touch foo/bar kuebert@gsows-eng138:~/tmp$ ls -l foo total 0 -rw-r--r-- 1 kuebert kuebert 0 2009-01-05 15:52 bar kuebert@gsows-eng138:~/tmp$ fakeroot chown root:root foo/bar kuebert@gsows-eng138:~/tmp$ ls -l foo total 0 -rw-r--r-- 1 kuebert kuebert 0 2009-01-05 15:52 bar kuebert@gsows-eng138:~/tmp$ rm -rf foo kuebert@gsows-eng138:~/tmp$ This is what happens on my network home drive (I did this on gsovm-psbs03): kuebert@gsovm-psbs01:~/tmp2$ mkdir foo kuebert@gsovm-psbs01:~/tmp2$ ls -l total 4 drwxr-xr-x 2 kuebert cvs 4096 2009-01-05 15:51 foo/ kuebert@gsovm-psbs01:~/tmp2$ fakeroot chown root:root foo kuebert@gsovm-psbs01:~/tmp2$ ls -l total 4 drwxr-xr-x 2 root root 4096 2009-01-05 15:51 foo/ kuebert@gsovm-psbs01:~/tmp2$ touch foo/bar touch: cannot touch `foo/bar': Permission denied kuebert@gsovm-psbs01:~/tmp2$ rm -rf foo kuebert@gsovm-psbs01:~/tmp2$ So basically what I think is happening is in the second case my fakeroot command is actually changing the file on the filesystem, at least from Linux's perspective, even though it's not supposed to. When I go to touch the file in the foo directory it won't let me because it thinks the directory is owned by root:root which it is not. Due to a problem like this I can't build deb packages without being root which is kind of a big deal (the dir permissions get hosed up and then the package creation fails). Jeremy M. Page________________ Systems Architect Gilbarco Veeder-Root, a Danaher Company 7300 West Friendly Avenue Greensboro, NC 22087 * email:Jeremy.Page@gilbarco.com - * phone: 336.547.5399 - 6 fax: 336.547.5163 - * cell: 336.601.7274 Open a Helpdesk Ticket <http://heat.gilbarco.com/heatselfservice/simple/en-us/> View the IT Wiki <http://gsovmwiki01.gilbarco.com/mediawiki/index.php/Main_Page> Please be advised that this email may contain confidential information. If you are not the intended recipient, please do not read, copy or re-transmit this email. If you have received this email in error, please notify us by email by replying to the sender and by telephone (call us collect at +1 202-828-0850) and delete this message and any attachments. Thank you in advance for your cooperation and assistance. In addition, Danaher and its subsidiaries disclaim that the content of this email constitutes an offer to enter into, or the acceptance of, any contract or agreement or any amendment thereto; provided that the foregoing disclaimer does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment to this email.

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