toasters

toasters@lists.teaparty.net

1 participants
13515 discussions

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

Upgarding filer head with LUNs and MSCS
by Borzenkov, Andrey 05 Jan '09

05 Jan '09

Hi, We are going to upgrade several filers (FAS270 -> FAS3140). They host FCP LUNs and Windows with MSCS connected. Now what I have been told: - MSCS records disks (LUNs) serial numbers; when these serial numbers change, MSCS won't detect and configure its disks. Basically, cluster has to be recreated from scratch - LUN serial number on filer depends on sysid; when sysid changes, LUN serial number will change - as during head upgrade sysid will change so will serial numbers; so MSCS will be very unhappy. Is the above correct? Now we'd rather avoid recreating all MSCS configuration. Are there any pitfalls if we save original serial numbers and set them again on new head before MSCS will go online? Will this work or some more tuning is necessary? Thank you! С уважением / With best regards / Mit freundlichen Grüβen --- Andrey Borzenkov Senior system engineer

3 3

Success using Bacula to back up an iSCSI-only NetApp
by David Lee Lambert 23 Dec '08

23 Dec '08

We have a two-controller FAS2020 NetApp with 1.5TB of storage (1TB on one, 500GB on the other), licensed for iSCSI only, and an old desktop system connected to a 12-tape library of LTO-4 (800GB uncompressed) tapes. I have gotten Bacula to back up files stored on ext3fs (Linux) and NTFS (Windows) partions on iSCSI LUNs on the NetApp. The Bacula instance is running under Ubuntu Gutsy (a "long-term supported" release), using the Gutsy package, 2.0.3. We're using Postgres version 8.2.5 as the database, because that's the available Ubuntu package and we use Postgres elsewhere. We're using the "open-iscsi" initiator, from an Ubuntu package. LVM and device-mapper are not installed on the backup-host, and it only has a single Fast Ethernet connection. (The hosts that are being backed up generally have dual Gigabit Ethernet connections to the filers.) I wrote several scripts to allow Bacula to take snapshots on the filer and mount them in a known place before the backup-job runs, then clean them up afterward. I can't publish them because they have a lot of details specific to our network, but the general outline is as follows: "easy_snap" takes 3 arguments: an NTFS or ext3fs volume-label, an indication of which filer the volume is on, and the complete path to the LUN on the filer (such as "/vol/vol5/testdatav2.lun"). It makes up a name to use for the snapshot. It issues "snap create", "lun clone create" and "lun map" commands via RSH to the filer. (It also checks to see if another snapshot of the same volume is still mounted by mistake; if so, it unmounts and unmaps it.) If another snapshot with the same name exists, the script tries to delete it, and renames it if that doesn't work. It cleans up any old "bacula-" snapshots. Then it issues a local "iscsiadm -m session --rescan" command, and if it still can't see the new LUN, logs the iSCSI session out and in again. It mounts the partition using "LABEL=" syntax, to a mount-point under /mnt where the last part is the lower-case form of the volume-label. "easy_unsnap" takes the same 3 arguments as "easy_snap". It unmounts the partition, logs out the iSCSI session, unmaps the LUN, and tries to delete the snapshot. We noticed that the snapshots weren't always being deleted, which is one reason why "easy_snap" tries to clean up old snapshots several ways. If a backup spans an hour-boundary where hourly snapshots are being created, or midnight for the nightly snapshot, the mapped LUN becomes part of the snapshot and the snapshot we took can't be deleted until the hourly or nightly snapshot goes away. I tried backing up Linux hosts with a filesystem on a raw (no partions) LUN using this script, but it didn't work: when the LUN is discovered, the /dev/disk/by-label/LABEL symlink does not get created. We wouldn't be able to back up LVM volumes with this configuration either, because LVM depends on device-mapper, and device-mapper would try to grab the disks itself. Right now our performance is limited by the network interface for LUNs containing a few large files, and by Postgres INSERT performance for filesystems with lots of small files. We get 9MByte/sec for the big-file LUNs, so for example a 46-GB SQL Server database takes an hour and 18 minutes to run. We have a test-system with over 300,000 files (including over 100,000 zero-length ones) in just a few directories, but only 580 MB of total data; that took two and a half hours to back up last night. However, our entire backup (except test-systems) ran within 6 hours, and we already have more than half of our production data being backed up with Bacula. For the most part, Bacula does what we want it to do in this case, and it allows a lot more flexibility with restoring files than we were able to achieve trying to use the "dump" command on the NetApp filers. -- David L. Lambert Yahoo! IM: davidleelambert ** MSN IM: lamber45(a)cse.msu.edu

1 0

Limiting SnapDrive user capabilities
by Borzenkov, Andrey 23 Dec '08

23 Dec '08

Hi, We are looking for a possibility to limit SnapDrive account to the bare minimum. The goal is to allow some SD operations (effectively, connecting and disconnecting snapshots) to a (Windows) user, while not giving this user full administrative capabilities on a filer. I have a feeling that careful usage of roles on filer could accomplish this; anybody has done it before? I would appreciate any hints. Thank you and Merry Christmas! С уважением / With best regards / Mit freundlichen Grüβen --- Andrey Borzenkov Senior system engineer

2 1

SMVI Command Line questions
by hollandwl＠gmail.com 23 Dec '08

23 Dec '08

Just started evaluating SMVI 1.01 in our Dev environment to get a feel for how it works. A couple of things showed up immediately that I could use some clarification on: 1. Is there any way to get it to simply pass the logged on Windows credentials and not prompt for a password the first time? The current behavior totally defeats the ability to script the operations as we do not wish to store passwords in clear text. 2. Is there any way to have it create backups/snapshots in a user friendly format? Using the -backup-name switch puts the name you enter into the snapshot name, but you still end up with something like smvi-backupname-someobscenelylonguid-volname. This naming convention makes integration with snapvault difficult as I know what name I pass with -backup-name, but don't know what the hiddeously long name is going to be. It would be EXTREMELY helfpful if the snapshot name were the same as -backup-name passed on the command line.

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