Nabble - Network Appliance - Toasters

looking for shelves

2009-12-11T02:32:27Z

I am looking for several netapp shelves to be delivered asap. FC300GB15K and 1TB SATA.

Anybody got any good ideas where to shop? Fast delivery is key!!

Re:

2009-12-10T06:51:09Z

You are correct and anyways migration would only work on the same filer.

Sorry for suggesting a dead end.

Joel

Michael Barrow wrote:

> 'snapmirror migrate' is only applicable for an existing SnapMirror
> relationship. In this particular instance, the SnapMirror relationship
> has effectively been torn down and a new relationship must be built.
>
> On Wed, Dec 9, 2009 at 5:56 AM, Joel Krajden <joelk@...
> <mailto:joelk@...>> wrote:
>
> You might want to look at
>
> Solution ID: kb40272
> Last updated: 30 SEP 2009
>
> Sample procedure using ' snapmirror migrate ' that avoids remounting
> in a NFS environment
>
>
>
> Joel
>
>
> John Stoffel wrote:
>
> "Fox," == Fox, Adam <Adam.Fox@...
> <mailto:Adam.Fox@...>> writes:
>
>
> Fox> VSM (and therefore SM2T) will preserve inodes, but it will
> be up
> Fox> to you to preserve the FSID of the original volume on east. If
> Fox> you go into priv set advanced, you will find 'vol
> read_fsid' and
> Fox> 'vol rewrite_fsid' which can accomplish this. Be aware that
> Fox> Rewriting the fsid requires the volume to be restricted and you
> Fox> will need to rewrite the original one first to something
> totally
> Fox> different. FSIDs must be unique not only within a
> controller but
> Fox> within an HA-pair if you want failover to work properly.
>
> Ouch! Sounds funky and possibly trouble.
>
> While I don't have any common snapshots between west> and east>
> filers, I do have some common snapshots on each filer for other
> snapmirror relationships, since west> is also snapmirroring tools to
> two other sites.
>
> Would it be possible to do the following:
>
> 1) quiece all snapmirrors of tools from west> to south> and
> north>
> - will this leave me with two snap shots for the west->north
> pair, or will snapmirror automatically cleanup when done?
>
> 2) comment out tools entries on all filers: west, south,
> north &
> east.
>
> 3) on west> (my source), do 'snap rename
> north(####)_tools.1234 \
> east(######)_tools.1234'
> 4) on east> snapmirror resynnc tools
>
> - wait until competed
>
> 5) on west> snap rename east(######)_tools.1234 \
> north(######)_tools.1234
> 6) do snap update tools on east, north, south to make sure they
> can all update again.
>
> 7) re-enable snapmirror.conf entries for tools.
>
> Or I wonder if I need to interrupt the west->north snapmirror in
> progress, and make sure I only rename the more recent snapshot, so
> that I still have valid snapshots between west->north, and now a
> second one to re-purpose as my west->east pair base?
>
> Any hope?
> Thanks,
> John
>
>
>
> Fox> While these commands are perfectly safe when used properly,
> they are
> Fox> guns so point them away from you (i.e. know what you're
> doing before you
> Fox> it or you could have a disruption you don't want).
>
> Fox> -- Adam Fox
> Fox> Systems Engineer
> Fox> adamfox@... <mailto:adamfox@...>
>
>
> Fox,> -----Original Message-----
> Fox,> From: John Stoffel [mailto:john.stoffel@...
> <mailto:john.stoffel@...>] Fox,> Sent: Monday,
> December 07, 2009 5:50 PM
> Fox,> To: toasters@... <mailto:toasters@...>
> Fox,> Subject: Redoing snapmirror to a destination
>
>
> Fox,> Guys,
>
> Fox,> Do to stupidity on my part, I managed to accidently delete
> a snapshot
> Fox,> on the source side of a snapmirror pair, so that
> snapmirror can't
> Fox,> continue. It's not critical, it's just our tools area,
> which isn't
> Fox,> updated frequently.
>
> Fox,> So now I want to re-snapmirror, but I want to limit the
> downtime of
> Fox,> the clients on the destination side as much as possible
> when I switch
> Fox,> them to the new re-snapmirrored volume.
>
> Fox,> Currently, my clients mount east:/vol/tools, so what I'd
> like to do
> Fox,> is:
>
> west> snapmirror store tools rst0a,rst1a
>
> east> vol create tools ....
> east> vol restrict tools
> east> snapmirror retrieve tools_new rst0a,rst1a
>
> Fox,> Now for the tricky part:
>
> east> nfs off
> east> vol rename tools tools_old
> east> vol rename tools_new tools
> east> nfs on
> east> exportfs -a -v
>
> Fox,> so that all my clients see (on a read-only volume) is a
> quick outage
> Fox,> or pause in NFS traffic, then they just continue on using
> tools and
> Fox,> such as usual.
>
> Fox,> Or will I be forced to reboot all of my client machines
> one by one?
> Fox,> Which will be truly truly truly painful...
>
> Fox,> The general snapmirror update and cleanup of the old volume is
> Fox,> trivial. It's limiting the outage to my clients that I
> worry about.
> Fox,> Thanks,
> Fox,> John
> Fox,> John Stoffel - Senior Staff Systems Administrator -
> System LSI Group
> Fox,> Toshiba America Electronic Components, Inc. -
> Fox,> http://www.toshiba.com/taec
> Fox,> john.stoffel@...
> <mailto:john.stoffel@...> - 508-486-1087
>
>
>
>
>
>
>
> --
> | Joel Krajden | Rm: EV-7105, Tel: 514 848-2424 3052 |
> | Core Technologies Mgr | |
> | Engineering & | Email: joelk@...
> <mailto:joelk@...> |
> | Computer Science | |
> | Concordia University | In a circus, the clowns are supposed |
> | Montreal, Canada | to make you laugh, not cry. |
>
>
>
>
> --
> Michael Barrow
> michael at barrow dot me
>

Netapp blog

2009-12-10T06:15:15Z

For some time now I have been adding items regarding issues and fixes with Netapp systems into a blog type format for myself. I have posted this blog online so everyone can enjoy! netappfas.blogspot.com

For now I have only migrated the old articles but am planning to add new ones regularly.

Re: migrating a volume with snapmirror

2009-12-09T13:23:45Z

So what I've ended up doing is just re-snapmirror to tape, FedEx, load
into a new volume. Now I need to switch all my clients to the new
volume. Easier said than done, since a bunch of long running user
processes are doing to slow this all down.

Then once that's all done, I then blow away the old volume and
re-create it, re-snapmirror it, and then switch everyone back. Mostly
because I want to keep the volume in the same aggr as before, but I
didn't quite have room for a second tools volume. Bummers.

Luckily, it's a low churn volume, so it should be ok.

Joel> Wonder if you can put the source volume into restricted mode
Joel> first and migrate will the open read or write simply continue if
Joel> the FSID are identical. It should but I have never tried it.

Joel> Ed Wilts wrote:

>> On Wed, Dec 9, 2009 at 7:56 AM, Joel Krajden <joelk@...
>> <mailto:joelk@...>> wrote:
>>
>> You might want to look at
>>
>> Solution ID: kb40272
>> Last updated: 30 SEP 2009
>>
>> Sample procedure using ' snapmirror migrate ' that avoids remounting
>> in a NFS environment
>>
>>
>> Unfortunately, it only works if all NFS access has stopped. If you
>> have just one host out there that you forgot about that is doing I/O to
>> the volume, it's remount time and users grumbling about stale handles.
>>
>> .../Ed
>>
>> Ed Wilts, RHCE, BCFP, BCSD, SCSP, SCSE
>> ewilts@... <mailto:ewilts@...>
>> Contact Me Linkedin <http://www.linkedin.com/in/ewilts>
>>
>>

Re: migrating a volume with snapmirror

2009-12-09T10:15:30Z

Wonder if you can put the source volume into restricted mode first and
migrate will the open read or write simply continue if the FSID are
identical. It should but I have never tried it.

Joel

Ed Wilts wrote:

> On Wed, Dec 9, 2009 at 7:56 AM, Joel Krajden <joelk@...
> <mailto:joelk@...>> wrote:
>
> You might want to look at
>
> Solution ID: kb40272
> Last updated: 30 SEP 2009
>
> Sample procedure using ' snapmirror migrate ' that avoids remounting
> in a NFS environment
>
>
> Unfortunately, it only works if all NFS access has stopped. If you
> have just one host out there that you forgot about that is doing I/O to
> the volume, it's remount time and users grumbling about stale handles.
>
> .../Ed
>
> Ed Wilts, RHCE, BCFP, BCSD, SCSP, SCSE
> ewilts@... <mailto:ewilts@...>
> Contact Me Linkedin <http://www.linkedin.com/in/ewilts>
>
>

Re:

2009-12-09T05:56:25Z

You might want to look at

Solution ID: kb40272
Last updated: 30 SEP 2009

Sample procedure using ' snapmirror migrate ' that avoids remounting in
a NFS environment

Joel

John Stoffel wrote:

>>>>>> "Fox," == Fox, Adam <Adam.Fox@...> writes:
>
> Fox> VSM (and therefore SM2T) will preserve inodes, but it will be up
> Fox> to you to preserve the FSID of the original volume on east. If
> Fox> you go into priv set advanced, you will find 'vol read_fsid' and
> Fox> 'vol rewrite_fsid' which can accomplish this. Be aware that
> Fox> Rewriting the fsid requires the volume to be restricted and you
> Fox> will need to rewrite the original one first to something totally
> Fox> different. FSIDs must be unique not only within a controller but
> Fox> within an HA-pair if you want failover to work properly.
>
> Ouch! Sounds funky and possibly trouble.
>
> While I don't have any common snapshots between west> and east>
> filers, I do have some common snapshots on each filer for other
> snapmirror relationships, since west> is also snapmirroring tools to
> two other sites.
>
> Would it be possible to do the following:
>
> 1) quiece all snapmirrors of tools from west> to south> and
> north>
> - will this leave me with two snap shots for the west->north
> pair, or will snapmirror automatically cleanup when done?
>
> 2) comment out tools entries on all filers: west, south, north &
> east.
>
> 3) on west> (my source), do 'snap rename north(####)_tools.1234 \
> east(######)_tools.1234'
>
> 4) on east> snapmirror resynnc tools
>
> - wait until competed
>
> 5) on west> snap rename east(######)_tools.1234 \
> north(######)_tools.1234
>
> 6) do snap update tools on east, north, south to make sure they
> can all update again.
>
> 7) re-enable snapmirror.conf entries for tools.
>
> Or I wonder if I need to interrupt the west->north snapmirror in
> progress, and make sure I only rename the more recent snapshot, so
> that I still have valid snapshots between west->north, and now a
> second one to re-purpose as my west->east pair base?
>
> Any hope?
>
> Thanks,
> John
>
>
>
> Fox> While these commands are perfectly safe when used properly, they are
> Fox> guns so point them away from you (i.e. know what you're doing before you
> Fox> it or you could have a disruption you don't want).
>
> Fox> -- Adam Fox
> Fox> Systems Engineer
> Fox> adamfox@...
>
>
> Fox,> -----Original Message-----
> Fox,> From: John Stoffel [mailto:john.stoffel@...]
> Fox,> Sent: Monday, December 07, 2009 5:50 PM
> Fox,> To: toasters@...
> Fox,> Subject: Redoing snapmirror to a destination
>
>
> Fox,> Guys,
>
> Fox,> Do to stupidity on my part, I managed to accidently delete a snapshot
> Fox,> on the source side of a snapmirror pair, so that snapmirror can't
> Fox,> continue. It's not critical, it's just our tools area, which isn't
> Fox,> updated frequently.
>
> Fox,> So now I want to re-snapmirror, but I want to limit the downtime of
> Fox,> the clients on the destination side as much as possible when I switch
> Fox,> them to the new re-snapmirrored volume.
>
> Fox,> Currently, my clients mount east:/vol/tools, so what I'd like to do
> Fox,> is:
>
> west> snapmirror store tools rst0a,rst1a
>
> east> vol create tools ....
> east> vol restrict tools
> east> snapmirror retrieve tools_new rst0a,rst1a
>
> Fox,> Now for the tricky part:
>
> east> nfs off
> east> vol rename tools tools_old
> east> vol rename tools_new tools
> east> nfs on
> east> exportfs -a -v
>
> Fox,> so that all my clients see (on a read-only volume) is a quick outage
> Fox,> or pause in NFS traffic, then they just continue on using tools and
> Fox,> such as usual.
>
> Fox,> Or will I be forced to reboot all of my client machines one by one?
> Fox,> Which will be truly truly truly painful...
>
> Fox,> The general snapmirror update and cleanup of the old volume is
> Fox,> trivial. It's limiting the outage to my clients that I worry about.
>
> Fox,> Thanks,
> Fox,> John
> Fox,> John Stoffel - Senior Staff Systems Administrator - System LSI Group
> Fox,> Toshiba America Electronic Components, Inc. -
> Fox,> http://www.toshiba.com/taec
> Fox,> john.stoffel@... - 508-486-1087
>
>
>
>

Re: Filers and anti virus software benefit

2009-12-09T00:46:47Z

Hi...

Well...we dont use any antivirus at all in our environment...and yes some home directories do have viruses etc...but that doesn't affect other users...since as a policy .exe files are not allowed in home directories...so better let em have it who keep EXEs in their home directories... :)
instead of keeping dedicated virus scanner servers,occupying rack space and power coupled with overheads of file access performance etc, better is to have better performance for majority of users and let few have the viruses...
Thanx

From: steve klise <klises@...>
To: toasters@...
Sent: Wed, December 9, 2009 2:08:00 AM
Subject: Re: Filers and anti virus software benefit

"Defense and Depth"..
http://en.wikipedia.org/wiki/Defense_in_Depth_(computing)

In my opinion, I have had viruses that were attempted to be uploaded to the
filer from users that HAD anti-virus protection, and after I implemented the
AV, I was able to scan some of the users shares, and found some viruses.
The problem was the users AV definition was out of date.

We use Trend and it is an inline scanner, as well as scans on a weekly
basis. I don't care for the trend product, but its what the org has paid
for, and it does work. The reporting for this product is very poor at best.

Hope this helps.

Joel Krajden wrote:

>
> Most of our clients (1000) accessing the filers for home directory
> shares are protected with an anti virus tool that scans a file on
> opening. There are unmanaged clients which have access to the filers and
> they may or may not be protected with an anti virus that is up to date,
> but they only risk infecting their own files in general.
>
> Is there any real benefit to having virus checking implemented on the
> filer as well. Given that zero day infections will not be stopped, the
> additional cost of dedicated virus scanners and software licensing is
> significant, the performance hit with thousands of users will be high;
> what have other filer administrators used as arguments for or against
> using these products.
>
> Any experience from administrators where the product has been of value?
>
>
> Joel
>
>
>

--
View this message in context: http://old.nabble.com/Filers-and-anti-virus-software-benefit-tp26700591p26700784.html
Sent from the Network Appliance - Toasters mailing list archive at Nabble.com.

Re: Filers and anti virus software benefit

2009-12-08T13:08:00Z

"Defense and Depth".. http://en.wikipedia.org/wiki/Defense_in_Depth_(computing)

In my opinion, I have had viruses that were attempted to be uploaded to the filer from users that HAD anti-virus protection, and after I implemented the AV, I was able to scan some of the users shares, and found some viruses. The problem was the users AV definition was out of date.

We use Trend and it is an inline scanner, as well as scans on a weekly basis. I don't care for the trend product, but its what the org has paid for, and it does work. The reporting for this product is very poor at best.

Hope this helps.

Joel Krajden wrote:

Most of our clients (1000) accessing the filers for home directory
shares are protected with an anti virus tool that scans a file on
opening. There are unmanaged clients which have access to the filers and
they may or may not be protected with an anti virus that is up to date,
but they only risk infecting their own files in general.

Is there any real benefit to having virus checking implemented on the
filer as well. Given that zero day infections will not be stopped, the
additional cost of dedicated virus scanners and software licensing is
significant, the performance hit with thousands of users will be high;
what have other filer administrators used as arguments for or against
using these products.

Any experience from administrators where the product has been of value?

Joel

Filers and anti virus software benefit

2009-12-08T12:19:21Z

Most of our clients (1000) accessing the filers for home directory
shares are protected with an anti virus tool that scans a file on
opening. There are unmanaged clients which have access to the filers and
they may or may not be protected with an anti virus that is up to date,
but they only risk infecting their own files in general.

Is there any real benefit to having virus checking implemented on the
filer as well. Given that zero day infections will not be stopped, the
additional cost of dedicated virus scanners and software licensing is
significant, the performance hit with thousands of users will be high;
what have other filer administrators used as arguments for or against
using these products.

Any experience from administrators where the product has been of value?

Joel

RE: Covert IBM N Series to NetApp Solution

2009-12-08T08:45:09Z

RE: Covert IBM N Series to NetApp Solution

We were talking about this off-the-cuff and believe you'd have to push the NetApp flash firmware to the controller to make it NetApp DOT friendly. I have heard reports of trying to load DOT on N-series and it won't boot... apparently IBM has modified (booby-trapped?) the firmware to refuse to accept generic NetApp DOT.

This is all speculation, so YMMV! But I'd be interested to know how your science project works out ;-)

-----Original Message-----
From: owner-toasters@... on behalf of Blake Golliher
Sent: Tue 12/8/2009 12:56 AM
To: ifstat
Cc: toasters@...
Subject: Re: Covert IBM N Series to NetApp Solution

Pardon me, but what's the point of doing that?

-Blake

On Mon, Dec 7, 2009 at 11:58 PM, ifstat <hockey@...> wrote:
>
> Ok, I'm sure this has been covered somewhere during the years, and I'm well
> aware that this is taboo in terms of the NetApp IBM partnership, but I would
> like to attempt or rather investigate the following:
>
> 1. Reconfigure an IBM N3700 to FAS270, initializing the disks and deploying
> NetApp Data ONTAP, does anyone know if the underlying hardware (firmware)
> will accept this.
>
> 2. Add NetApp disks and shelves to the system, ie grow with NetApp directly
> and not neccessarily IBM.
>
> Anyone attempted this your info would be helpful.
>
> We are not concerned about the support agreements, financially NetApp is
> cheaper and easier, so in this day and age it all about the MONEY:).
>
> --
> View this message in context: http://old.nabble.com/Covert-IBM-N-Series-to-NetApp-Solution-tp26690019p26690019.html
> Sent from the Network Appliance - Toasters mailing list archive at Nabble.com.
>
>

Re: Covert IBM N Series to NetApp Solution

2009-12-08T00:56:48Z

Pardon me, but what's the point of doing that?

-Blake

On Mon, Dec 7, 2009 at 11:58 PM, ifstat <hockey@...> wrote:

>
> Ok, I'm sure this has been covered somewhere during the years, and I'm well
> aware that this is taboo in terms of the NetApp IBM partnership, but I would
> like to attempt or rather investigate the following:
>
> 1. Reconfigure an IBM N3700 to FAS270, initializing the disks and deploying
> NetApp Data ONTAP, does anyone know if the underlying hardware (firmware)
> will accept this.
>
> 2. Add NetApp disks and shelves to the system, ie grow with NetApp directly
> and not neccessarily IBM.
>
> Anyone attempted this your info would be helpful.
>
> We are not concerned about the support agreements, financially NetApp is
> cheaper and easier, so in this day and age it all about the MONEY:).
>
> --
> View this message in context: http://old.nabble.com/Covert-IBM-N-Series-to-NetApp-Solution-tp26690019p26690019.html
> Sent from the Network Appliance - Toasters mailing list archive at Nabble.com.
>
>

Covert IBM N Series to NetApp Solution

2009-12-07T23:58:19Z

Ok, I'm sure this has been covered somewhere during the years, and I'm well aware that this is taboo in terms of the NetApp IBM partnership, but I would like to attempt or rather investigate the following:

1. Reconfigure an IBM N3700 to FAS270, initializing the disks and deploying NetApp Data ONTAP, does anyone know if the underlying hardware (firmware) will accept this.

2. Add NetApp disks and shelves to the system, ie grow with NetApp directly and not neccessarily IBM.

Anyone attempted this your info would be helpful.

We are not concerned about the support agreements, financially NetApp is cheaper and easier, so in this day and age it all about the MONEY:).

Re:

2009-12-07T20:51:32Z

>>>>> "Fox," == Fox, Adam <Adam.Fox@...> writes:

Fox> VSM (and therefore SM2T) will preserve inodes, but it will be up
Fox> to you to preserve the FSID of the original volume on east. If
Fox> you go into priv set advanced, you will find 'vol read_fsid' and
Fox> 'vol rewrite_fsid' which can accomplish this. Be aware that
Fox> Rewriting the fsid requires the volume to be restricted and you
Fox> will need to rewrite the original one first to something totally
Fox> different. FSIDs must be unique not only within a controller but
Fox> within an HA-pair if you want failover to work properly.

Ouch! Sounds funky and possibly trouble.

While I don't have any common snapshots between west> and east>
filers, I do have some common snapshots on each filer for other
snapmirror relationships, since west> is also snapmirroring tools to
two other sites.

Would it be possible to do the following:

1) quiece all snapmirrors of tools from west> to south> and
north>
- will this leave me with two snap shots for the west->north
pair, or will snapmirror automatically cleanup when done?

2) comment out tools entries on all filers: west, south, north &
east.

3) on west> (my source), do 'snap rename north(####)_tools.1234 \
east(######)_tools.1234'

4) on east> snapmirror resynnc tools

- wait until competed

5) on west> snap rename east(######)_tools.1234 \
north(######)_tools.1234

6) do snap update tools on east, north, south to make sure they
can all update again.

7) re-enable snapmirror.conf entries for tools.

Or I wonder if I need to interrupt the west->north snapmirror in
progress, and make sure I only rename the more recent snapshot, so
that I still have valid snapshots between west->north, and now a
second one to re-purpose as my west->east pair base?

Any hope?

Thanks,
John

Fox> While these commands are perfectly safe when used properly, they are
Fox> guns so point them away from you (i.e. know what you're doing before you
Fox> it or you could have a disruption you don't want).

Fox> -- Adam Fox
Fox> Systems Engineer
Fox> adamfox@...

Fox,> -----Original Message-----
Fox,> From: John Stoffel [mailto:john.stoffel@...]
Fox,> Sent: Monday, December 07, 2009 5:50 PM
Fox,> To: toasters@...
Fox,> Subject: Redoing snapmirror to a destination

Fox,> Guys,

Fox,> Do to stupidity on my part, I managed to accidently delete a snapshot
Fox,> on the source side of a snapmirror pair, so that snapmirror can't
Fox,> continue. It's not critical, it's just our tools area, which isn't
Fox,> updated frequently.

Fox,> So now I want to re-snapmirror, but I want to limit the downtime of
Fox,> the clients on the destination side as much as possible when I switch
Fox,> them to the new re-snapmirrored volume.

Fox,> Currently, my clients mount east:/vol/tools, so what I'd like to do
Fox,> is:

west> snapmirror store tools rst0a,rst1a

east> vol create tools ....
east> vol restrict tools
east> snapmirror retrieve tools_new rst0a,rst1a

Fox,> Now for the tricky part:

east> nfs off
east> vol rename tools tools_old
east> vol rename tools_new tools
east> nfs on
east> exportfs -a -v

Fox,> so that all my clients see (on a read-only volume) is a quick outage
Fox,> or pause in NFS traffic, then they just continue on using tools and
Fox,> such as usual.

Fox,> Or will I be forced to reboot all of my client machines one by one?
Fox,> Which will be truly truly truly painful...

Fox,> The general snapmirror update and cleanup of the old volume is
Fox,> trivial. It's limiting the outage to my clients that I worry about.

Fox,> Thanks,
Fox,> John
Fox,> John Stoffel - Senior Staff Systems Administrator - System LSI Group
Fox,> Toshiba America Electronic Components, Inc. -
Fox,> http://www.toshiba.com/taec
Fox,> john.stoffel@... - 508-486-1087

RE:

2009-12-07T16:07:25Z

It might be a good idea to test your procedure within a pair of
snapmirrored simulator instances before you do this with live data.
That saved my behind more than once :)

Richard Barlow
Senior Systems Engineer
Virtualization Specialist
NetApp
804.929.2500

www.netapp.com

-----Original Message-----
From: Fox, Adam
Sent: Monday, December 07, 2009 6:56 PM
To: John Stoffel; toasters@...
Subject:

VSM (and therefore SM2T) will preserve inodes, but it will be up to you
to preserve the FSID of the original volume on east.
If you go into priv set advanced, you will find 'vol read_fsid' and 'vol
rewrite_fsid' which can accomplish this. Be aware that
Rewriting the fsid requires the volume to be restricted and you will
need to rewrite the original one first to something totally different.
FSIDs must be unique not only within a controller but within an HA-pair
if you want failover to work properly.

While these commands are perfectly safe when used properly, they are
guns so point them away from you (i.e. know what you're doing before you
it or you could have a disruption you don't want).

-- Adam Fox
Systems Engineer
adamfox@...

-----Original Message-----
From: John Stoffel [mailto:john.stoffel@...]
Sent: Monday, December 07, 2009 5:50 PM
To: toasters@...
Subject: Redoing snapmirror to a destination

Guys,

Do to stupidity on my part, I managed to accidently delete a snapshot
on the source side of a snapmirror pair, so that snapmirror can't
continue. It's not critical, it's just our tools area, which isn't
updated frequently.

So now I want to re-snapmirror, but I want to limit the downtime of
the clients on the destination side as much as possible when I switch
them to the new re-snapmirrored volume.

Currently, my clients mount east:/vol/tools, so what I'd like to do
is:

west> snapmirror store tools rst0a,rst1a

east> vol create tools ....
east> vol restrict tools
east> snapmirror retrieve tools_new rst0a,rst1a

Now for the tricky part:

east> nfs off
east> vol rename tools tools_old
east> vol rename tools_new tools
east> nfs on
east> exportfs -a -v

so that all my clients see (on a read-only volume) is a quick outage
or pause in NFS traffic, then they just continue on using tools and
such as usual.

Or will I be forced to reboot all of my client machines one by one?
Which will be truly truly truly painful...

The general snapmirror update and cleanup of the old volume is
trivial. It's limiting the outage to my clients that I worry about.

Thanks,
John
John Stoffel - Senior Staff Systems Administrator - System LSI Group
Toshiba America Electronic Components, Inc. -
http://www.toshiba.com/taec
john.stoffel@... - 508-486-1087

(no subject)

2009-12-07T15:55:53Z

VSM (and therefore SM2T) will preserve inodes, but it will be up to you
to preserve the FSID of the original volume on east.
If you go into priv set advanced, you will find 'vol read_fsid' and 'vol
rewrite_fsid' which can accomplish this. Be aware that
Rewriting the fsid requires the volume to be restricted and you will
need to rewrite the original one first to something totally different.
FSIDs must be unique not only within a controller but within an HA-pair
if you want failover to work properly.

While these commands are perfectly safe when used properly, they are
guns so point them away from you (i.e. know what you're doing before you
it or you could have a disruption you don't want).

-- Adam Fox
Systems Engineer
adamfox@...

-----Original Message-----
From: John Stoffel [mailto:john.stoffel@...]
Sent: Monday, December 07, 2009 5:50 PM
To: toasters@...
Subject: Redoing snapmirror to a destination

Guys,

Do to stupidity on my part, I managed to accidently delete a snapshot
on the source side of a snapmirror pair, so that snapmirror can't
continue. It's not critical, it's just our tools area, which isn't
updated frequently.

So now I want to re-snapmirror, but I want to limit the downtime of
the clients on the destination side as much as possible when I switch
them to the new re-snapmirrored volume.

Currently, my clients mount east:/vol/tools, so what I'd like to do
is:

west> snapmirror store tools rst0a,rst1a

east> vol create tools ....
east> vol restrict tools
east> snapmirror retrieve tools_new rst0a,rst1a

Now for the tricky part:

east> nfs off
east> vol rename tools tools_old
east> vol rename tools_new tools
east> nfs on
east> exportfs -a -v

so that all my clients see (on a read-only volume) is a quick outage
or pause in NFS traffic, then they just continue on using tools and
such as usual.

Or will I be forced to reboot all of my client machines one by one?
Which will be truly truly truly painful...

The general snapmirror update and cleanup of the old volume is
trivial. It's limiting the outage to my clients that I worry about.

Thanks,
John
John Stoffel - Senior Staff Systems Administrator - System LSI Group
Toshiba America Electronic Components, Inc. -
http://www.toshiba.com/taec
john.stoffel@... - 508-486-1087

Re: Redoing snapmirror to a destination

2009-12-07T15:52:51Z

I just double checked and I don't have any common snapshots unfortunately.
Time to file a req with netapp to make 'snap delete ...' Be less permissive in deleting snapshots used for any snap* relationships without a force switch of some sort...

Thanks,
John stoffel

----- Original Message -----
From: Michael Barrow [michael@...]
Sent: 12/07/2009 03:02 PM PST
To: John Stoffel
Cc: <toasters@...>
Subject: Re: Redoing snapmirror to a destination

Do you not have *any* Snapshots in common between the source and destination? If you have common Snapshots, you can issue a 'snapmirror resync' on the destination and the relationship will be established.

This is better than swapping the volume because you'll likely get stale file handles.

--
Michael Barrow
michael at barrow dot me

On Dec 7, 2009, at 2:50 PM, John Stoffel wrote:

>
> Guys,
>
> Do to stupidity on my part, I managed to accidently delete a snapshot
> on the source side of a snapmirror pair, so that snapmirror can't
> continue. It's not critical, it's just our tools area, which isn't
> updated frequently.
>
> So now I want to re-snapmirror, but I want to limit the downtime of
> the clients on the destination side as much as possible when I switch
> them to the new re-snapmirrored volume.
>
> Currently, my clients mount east:/vol/tools, so what I'd like to do
> is:
>
> west> snapmirror store tools rst0a,rst1a
>
> east> vol create tools ....
> east> vol restrict tools
> east> snapmirror retrieve tools_new rst0a,rst1a
>
> Now for the tricky part:
>
> east> nfs off
> east> vol rename tools tools_old
> east> vol rename tools_new tools
> east> nfs on
> east> exportfs -a -v
>
> so that all my clients see (on a read-only volume) is a quick outage
> or pause in NFS traffic, then they just continue on using tools and
> such as usual.
>
> Or will I be forced to reboot all of my client machines one by one?
> Which will be truly truly truly painful...
>
> The general snapmirror update and cleanup of the old volume is
> trivial. It's limiting the outage to my clients that I worry about.
>
> Thanks,
> John
> John Stoffel - Senior Staff Systems Administrator - System LSI Group
> Toshiba America Electronic Components, Inc. - http://www.toshiba.com/taec
> john.stoffel@... - 508-486-1087
>
>
>
>

Re: Redoing snapmirror to a destination

2009-12-07T15:42:45Z

Hmmm fsid is something to keep in mind. I can do a couple of tests vols later to see what happens.

Thanks for the feedback all!

Thanks,
John stoffel

----- Original Message -----
From: Bert Kiers [kiersb@...]
Sent: 12/08/2009 12:34 AM CET
To: John Stoffel
Cc: toasters@...
Subject: Re: Redoing snapmirror to a destination

On Mon, Dec 07, 2009 at 05:50:20PM -0500, John Stoffel wrote:

Hi,

> so that all my clients see (on a read-only volume) is a quick outage
> or pause in NFS traffic, then they just continue on using tools and
> such as usual.

> Or will I be forced to reboot all of my client machines one by one?
> Which will be truly truly truly painful...

The trick is to keep the fsid the same. I doubt the steps you outline
will do that. Is it possible to tell a filer to use a particular fsid
for a volume? (I guess snapmirror does not change inodes, what is also
needed here.)

Grtnx,
--
Bert Kiers
XS4ALL UNIX systeembeheerder, suspected terrorist
1984 was not meant as a manual

Re: Redoing snapmirror to a destination

2009-12-07T15:34:04Z

On Mon, Dec 07, 2009 at 05:50:20PM -0500, John Stoffel wrote:

Hi,

> so that all my clients see (on a read-only volume) is a quick outage
> or pause in NFS traffic, then they just continue on using tools and
> such as usual.

> Or will I be forced to reboot all of my client machines one by one?
> Which will be truly truly truly painful...

The trick is to keep the fsid the same. I doubt the steps you outline
will do that. Is it possible to tell a filer to use a particular fsid
for a volume? (I guess snapmirror does not change inodes, what is also
needed here.)

Grtnx,
--
Bert Kiers
XS4ALL UNIX systeembeheerder, suspected terrorist
1984 was not meant as a manual

Re: Redoing snapmirror to a destination

2009-12-07T15:31:53Z

No common snaps that I know of, but its a good idea.

John
Thanks,
John stoffel

----- Original Message -----
From: "Page, Jeremy" [jeremy.page@...]
Sent: 12/07/2009 03:04 PM PST
To: John Stoffel; <toasters@...>
Subject: RE: Redoing snapmirror to a destination

I think you can resynch if there are any common snapshots, did you call
Netapp?

-----Original Message-----
From: owner-toasters@... [mailto:owner-toasters@...]
On Behalf Of John Stoffel
Sent: Monday, December 07, 2009 5:50 PM
To: toasters@...
Subject: Redoing snapmirror to a destination

Guys,

Do to stupidity on my part, I managed to accidently delete a snapshot
on the source side of a snapmirror pair, so that snapmirror can't
continue. It's not critical, it's just our tools area, which isn't
updated frequently.

So now I want to re-snapmirror, but I want to limit the downtime of
the clients on the destination side as much as possible when I switch
them to the new re-snapmirrored volume.

Currently, my clients mount east:/vol/tools, so what I'd like to do
is:

west> snapmirror store tools rst0a,rst1a

east> vol create tools ....
east> vol restrict tools
east> snapmirror retrieve tools_new rst0a,rst1a

Now for the tricky part:

east> nfs off
east> vol rename tools tools_old
east> vol rename tools_new tools
east> nfs on
east> exportfs -a -v

so that all my clients see (on a read-only volume) is a quick outage
or pause in NFS traffic, then they just continue on using tools and
such as usual.

Or will I be forced to reboot all of my client machines one by one?
Which will be truly truly truly painful...

The general snapmirror update and cleanup of the old volume is
trivial. It's limiting the outage to my clients that I worry about.

Thanks,
John
John Stoffel - Senior Staff Systems Administrator - System LSI Group
Toshiba America Electronic Components, Inc. -
http://www.toshiba.com/taec
john.stoffel@... - 508-486-1087

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.

RE: Redoing snapmirror to a destination

2009-12-07T15:21:06Z

The quickie rename won't work unless you hack the fsid
of the new volume to match the fsid of the old volume.
Even then, it is pretty high risk.

If it isn't updated often, and you have space, just do
a new snapmirror, and change the mount point on the clients
over time.

John

-----Original Message-----
From: owner-toasters@... [mailto:owner-toasters@...] On Behalf Of John Stoffel
Sent: Monday, December 07, 2009 2:50 PM
To: toasters@...
Subject: Redoing snapmirror to a destination

Guys,

Do to stupidity on my part, I managed to accidently delete a snapshot
on the source side of a snapmirror pair, so that snapmirror can't
continue. It's not critical, it's just our tools area, which isn't
updated frequently.

So now I want to re-snapmirror, but I want to limit the downtime of
the clients on the destination side as much as possible when I switch
them to the new re-snapmirrored volume.

Currently, my clients mount east:/vol/tools, so what I'd like to do
is:

west> snapmirror store tools rst0a,rst1a

east> vol create tools ....
east> vol restrict tools
east> snapmirror retrieve tools_new rst0a,rst1a

Now for the tricky part:

east> nfs off
east> vol rename tools tools_old
east> vol rename tools_new tools
east> nfs on
east> exportfs -a -v

so that all my clients see (on a read-only volume) is a quick outage
or pause in NFS traffic, then they just continue on using tools and
such as usual.

Or will I be forced to reboot all of my client machines one by one?
Which will be truly truly truly painful...

The general snapmirror update and cleanup of the old volume is
trivial. It's limiting the outage to my clients that I worry about.

Thanks,
John
John Stoffel - Senior Staff Systems Administrator - System LSI Group
Toshiba America Electronic Components, Inc. - http://www.toshiba.com/taec
john.stoffel@... - 508-486-1087

RE: Redoing snapmirror to a destination

2009-12-07T15:04:11Z

I think you can resynch if there are any common snapshots, did you call
Netapp?

-----Original Message-----
From: owner-toasters@... [mailto:owner-toasters@...]
On Behalf Of John Stoffel
Sent: Monday, December 07, 2009 5:50 PM
To: toasters@...
Subject: Redoing snapmirror to a destination

Guys,

Do to stupidity on my part, I managed to accidently delete a snapshot
on the source side of a snapmirror pair, so that snapmirror can't
continue. It's not critical, it's just our tools area, which isn't
updated frequently.

So now I want to re-snapmirror, but I want to limit the downtime of
the clients on the destination side as much as possible when I switch
them to the new re-snapmirrored volume.

Currently, my clients mount east:/vol/tools, so what I'd like to do
is:

west> snapmirror store tools rst0a,rst1a

east> vol create tools ....
east> vol restrict tools
east> snapmirror retrieve tools_new rst0a,rst1a

Now for the tricky part:

east> nfs off
east> vol rename tools tools_old
east> vol rename tools_new tools
east> nfs on
east> exportfs -a -v

so that all my clients see (on a read-only volume) is a quick outage
or pause in NFS traffic, then they just continue on using tools and
such as usual.

Or will I be forced to reboot all of my client machines one by one?
Which will be truly truly truly painful...

The general snapmirror update and cleanup of the old volume is
trivial. It's limiting the outage to my clients that I worry about.

Thanks,
John
John Stoffel - Senior Staff Systems Administrator - System LSI Group
Toshiba America Electronic Components, Inc. -
http://www.toshiba.com/taec
john.stoffel@... - 508-486-1087

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.

Redoing snapmirror to a destination

2009-12-07T14:50:20Z

Guys,

Do to stupidity on my part, I managed to accidently delete a snapshot
on the source side of a snapmirror pair, so that snapmirror can't
continue. It's not critical, it's just our tools area, which isn't
updated frequently.

So now I want to re-snapmirror, but I want to limit the downtime of
the clients on the destination side as much as possible when I switch
them to the new re-snapmirrored volume.

Currently, my clients mount east:/vol/tools, so what I'd like to do
is:

west> snapmirror store tools rst0a,rst1a

east> vol create tools ....
east> vol restrict tools
east> snapmirror retrieve tools_new rst0a,rst1a

Now for the tricky part:

east> nfs off
east> vol rename tools tools_old
east> vol rename tools_new tools
east> nfs on
east> exportfs -a -v

so that all my clients see (on a read-only volume) is a quick outage
or pause in NFS traffic, then they just continue on using tools and
such as usual.

Or will I be forced to reboot all of my client machines one by one?
Which will be truly truly truly painful...

The general snapmirror update and cleanup of the old volume is
trivial. It's limiting the outage to my clients that I worry about.

Thanks,
John
John Stoffel - Senior Staff Systems Administrator - System LSI Group
Toshiba America Electronic Components, Inc. - http://www.toshiba.com/taec
john.stoffel@... - 508-486-1087

Re: Does anyone know if the dedup is across the entire aggr or just the volume in 7.3.x?

2009-12-07T11:00:31Z

Page, Jeremy wrote:
> Does anyone know if the dedup is across the entire aggr or just the
> volume in 7.3.x? I’d like to break up my VMware environment so we have a
> volume per service (so SQL Warehouse volume, Call Center etc). This
> would be nice because we could delegate the rights to them, move them
> around if specific apps required more IO and aid in troubleshooting. The
> question I have is will this kill our dedup percentages?

It is still just at the volume level.

--rdp

Does anyone know if the dedup is across the entire aggr or just the volume in 7.3.x?

2009-12-07T10:39:36Z

Does anyone know if the dedup is across the entire aggr or just the volume in 7.3.x? I’d like to break up my VMware environment so we have a volume per service (so SQL Warehouse volume, Call Center etc). This would be nice because we could delegate the rights to them, move them around if specific apps required more IO and aid in troubleshooting. The question I have is will this kill our dedup percentages?

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.

Re: SMVI 2.0 problem

2009-12-02T11:21:47Z

ok, just got it fixed. Thanks Netapp Support!!

Turns out we did a Limited Self-Service instead of a self serivce. I noticed there were snapshots from an old set of LUNS when I did a search for all for our target VM. I noticed some snapshots that are no longer valid, as in, under my Inventory tab, I removed all the older LUNS that we were using for test.

works like a charm now.. Back to lovin' my netapps....

steve klise wrote:

ok, scratching my head here...

I just upgraded the new SMVI 2.0 with file level restore.. HURAYY.. Its only been a year, but I guess you cant rush perfection. I was previously running 1.2 and have the typical wait time errors, but for the most part is successful.

Specs:
ESX vshpere 4.0 (non 4i flavor)
SMIV 2.0 (installed on VMWare VIC physical server)
6040's DOT 7.3.11
FC
HP DL380s G5(for now)

problem:
When I try and do a single file restore via self service option, (to and from the same VM guest), I go to select the vm in the restore agent from the guest OS, I press OK. Then I get an error:

Failed to retrieve backupList fro the source guest. And I only have an OK button.

i have tried from multiple guest os'es. Same result.

I looked in the log, and this is just before the popup I get:

at RestoreAgentWCFSvc.RestoreAgent.GetBackupsAndDisks(GuestIdentifier guest, List`1& backupRootedHierarchy, List`1& diskRootedHierarchy, Exception& exFromHyperVisor)
then the error in the log..

11/23/2009 01:31:48:154 (PID:01684 ,TID:00006): Failed to retrieve backupList for the source guest

Any help is appreciated..

RE: Some disks showing as 0.0GB 0B/sect (Found in scan)

2009-11-30T08:37:12Z

All,

Thank you to those you replied to me directly with suggestions.. My NetApp SE came up with a solution that resolved my specific problem. This was to boot into maintenance mode and run “scsi format <diskID>” on the disks not already sanitized.

Regards

Keith

From: owner-toasters@... [mailto:owner-toasters@...] On Behalf Of Keith Howlett
Sent: 26 November 2009 16:33
To: toasters@...
Subject: Some disks showing as 0.0GB 0B/sect (Found in scan)

Hi,

I am in the final stages of decommissioning a pair of FAS3020 filers and have been running the disk sanitize commands to erase all our data before the systems go back to NetApp (trade in deal as part of the purchase of a FAS3140) . They are no longer on support so I can’t open a case with NetApp.

During the execution of the disk sanitize command to clear the final few discs it hung at 9% completed, and would not proceed beyond that. All activity on those specific disks had ceased. If I run a sysconfig –a they now report as 0.0GB 0B/sect (Found in scan)

I have tried the privileged command disk unfail –s <diskname> (which I have used to clear BAD_LABEL faults) but the system now reports the disks as not being found. A reboot has made no difference.

The only item I could find in the NetApp KB was around software based disc ownership, but we do not have software ownership enabled on the disks/filers.

Whilst I could just ship it back to NetApp as it is, I would like to get the discs back online to complete the disk sanitization process.

I have tried moving the failed disks to another shelf, but the fail remains so it is the disks and not the shelf.

Any ideas ?

Thanks

Keith

Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.

Re: Snapdrive alternative

2009-11-29T02:58:36Z

Hi,

I am not sure if there is an alternative to snapmanager & snapdrive when using NetApp storage, but there is alternative if you are still planning on which storage you are going to buy. IBM has an offering called IBM Tivoli FlashCopy Manager, but that still limited to IBM Storage & does not support NetApp filers yet. Though as I mentioned if you still got the option to choose your storage, you might want to check it out.
You can find a bit of more info on IBM Tivoli Storage FlashCopy Manager at:

NetApp SnapManager Buster or as called by IBM Tivoli Storage FlashCopy Manager

We have tested IBM Tivoli FlashCopy Manager for SQL few weeks ago & it was amazing fast & quite stable.

I hope this help,
Erick
Linux & IBM AIX Blog

bluezman wrote:

We found that snapdrive is not very stable. Are there any alternatives ?

Setup is as follows
Win 2k3 servers
Sql dbs
3070c running 7.2.2
With fiber
Sent via BlackBerry from T-Mobile

Some disks showing as 0.0GB 0B/sect (Found in scan)

2009-11-26T08:32:34Z

Hi,

I have tried the privileged command disk unfail –s <diskname> (which I have used to clear BAD_LABEL faults) but the system now reports the disks as not being found. A reboot has made no difference.

The only item I could find in the NetApp KB was around software based disc ownership, but we do not have software ownership enabled on the disks/filers.

Whilst I could just ship it back to NetApp as it is, I would like to get the discs back online to complete the disk sanitization process.

I have tried moving the failed disks to another shelf, but the fail remains so it is the disks and not the shelf.

Any ideas ?

Thanks

Keith

Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.

RE: Power change 110 to 208v without downtime

2009-11-23T17:48:43Z

Now that's why I like toasters.

-----Original Message-----
From: Brad Reger [mailto:reger@...]
Sent: Monday, November 23, 2009 5:33 PM
To: Learmonth, Peter; Page, Jeremy
Cc: toasters@...
Subject: Re: Power change 110 to 208v without downtime

We in Engineering think this is fine and works.
It's probably obvious but:

1. observe software environmental monitoring to verify both PSUs are up
and
running.
2. power off one PSU (using AC switch on PSU)
3. unplug from 110V and plug into 208V
4. power it back on
5. observe software environmental monitoring to verify new PSU is up and
running.
6. repeat process for the other PSU
7. observe software environmental monitoring to verify both PSUs are up
and
running.

Brad.

[mailto:owner-toasters@...]
> On Behalf Of Kevin H. Schoener
> Sent: Monday, November 23, 2009 3:25 PM
> To: Bill Holland; Suresh Rajagopalan
> Cc: toasters@...
> Subject: RE: Power change 110 to 208v without downtime
>
>
>
> ..shouldn't be a problem. The low-side of the Power Supply is the
same

> for both high-side voltages. So, assuming you're plugging into a 208V
> power source on the "new" Power Supplies, it should work fine.
>
>
>
> Best Regards,
>
> Kevin
>
> ________________________________
>
> From: owner-toasters@...

[mailto:owner-toasters@...]
> On Behalf Of Bill Holland
> Sent: Monday, November 23, 2009 2:59 PM
> To: Suresh Rajagopalan
> Cc: toasters@...
> Subject: Re: Power change 110 to 208v without downtime
>
>
>
> I certainly would not be brave enough to try that. Not sure what
having
> 208 on one side and 110 on the other would do, but seems like a
> potential for disaster.
>
> On Mon, Nov 23, 2009 at 2:31 PM, Suresh Rajagopalan
> <SRajagopalan@...> wrote:
>
> Our filers and shelves are currently on 110v power. We'd like to
switch
> to 208v, possibly without downtime. I'm thinking of moving each power
> supply one by one from 110v to 208v. Are there any issues doing it
this
> way?
>
>
>
> Thanks
>
> Suresh

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.

Re: Power change 110 to 208v without downtime

2009-11-23T14:32:59Z

We in Engineering think this is fine and works.
It's probably obvious but:

1. observe software environmental monitoring to verify both PSUs are up and
running.
2. power off one PSU (using AC switch on PSU)
3. unplug from 110V and plug into 208V
4. power it back on
5. observe software environmental monitoring to verify new PSU is up and
running.
6. repeat process for the other PSU
7. observe software environmental monitoring to verify both PSUs are up and
running.

Brad.

> From: "Learmonth, Peter" <Peter.Learmonth@...>
> Date: Mon, 23 Nov 2009 13:20:40 -0800
> To: "Page, Jeremy" <jeremy.page@...>
> Cc: <toasters@...>
> Subject: RE: Power change 110 to 208v without downtime
>
> It works. I've done it. Gotta check on support.
>
> -----Original Message-----
> From: Page, Jeremy <jeremy.page@...>
> Sent: Monday, November 23, 2009 12:48 PM
> Cc: toasters@... <toasters@...>
> Subject: RE: Power change 110 to 208v without downtime
>
> Let us know if it works :-)
>
> ________________________________
>
> From: owner-toasters@... [mailto:owner-toasters@...]
> On Behalf Of Kevin H. Schoener
> Sent: Monday, November 23, 2009 3:25 PM
> To: Bill Holland; Suresh Rajagopalan
> Cc: toasters@...
> Subject: RE: Power change 110 to 208v without downtime
>
>
>
> ..shouldn't be a problem. The low-side of the Power Supply is the same
> for both high-side voltages. So, assuming you're plugging into a 208V
> power source on the "new" Power Supplies, it should work fine.
>
>
>
> Best Regards,
>
> Kevin
>
> ________________________________
>
> From: owner-toasters@... [mailto:owner-toasters@...]
> On Behalf Of Bill Holland
> Sent: Monday, November 23, 2009 2:59 PM
> To: Suresh Rajagopalan
> Cc: toasters@...
> Subject: Re: Power change 110 to 208v without downtime
>
>
>
> I certainly would not be brave enough to try that. Not sure what having
> 208 on one side and 110 on the other would do, but seems like a
> potential for disaster.
>
> On Mon, Nov 23, 2009 at 2:31 PM, Suresh Rajagopalan
> <SRajagopalan@...> wrote:
>
> Our filers and shelves are currently on 110v power. We'd like to switch
> to 208v, possibly without downtime. I'm thinking of moving each power
> supply one by one from 110v to 208v. Are there any issues doing it this
> way?
>
>
>
> Thanks
>
> Suresh

RE: SMVI 2.0 problem

2009-11-23T14:03:23Z

Here are couple of things to check:
1. Make sure the SFR session you created is still active and not
expired. You can check it from Restore GUI page.
2. Check and adjust firewall rules on your SMVI server machine to allow
incoming connections on port# 8043.

-----Original Message-----
From: steve klise [mailto:klises@...]
Sent: Monday, November 23, 2009 1:38 PM
To: toasters@...
Subject: SMVI 2.0 problem

ok, scratching my head here...

I just upgraded the new SMVI 2.0 with file level restore.. HURAYY.. Its
only been a year, but I guess you cant rush perfection. I was
previously running
1.2 and have the typical wait time errors, but for the most part is
successful.

Specs:
ESX vshpere 4.0 (non 4i flavor)
SMIV 2.0 (installed on VMWare VIC physical server) 6040's DOT 7.3.11 FC
HP DL380s G5(for now)

problem:
When I try and do a single file restore via self service option, (to and
from the same VM guest), I go to select the vm in the restore agent from
the guest OS, I press OK. Then I get an error:

Failed to retrieve backupList fro the source guest. And I only have an
OK button.

i have tried from multiple guest os'es. Same result.

I looked in the log, and this is just before the popup I get:

at RestoreAgentWCFSvc.RestoreAgent.GetBackupsAndDisks(GuestIdentifier
guest, List`1& backupRootedHierarchy, List`1& diskRootedHierarchy,
Exception& exFromHyperVisor) then the error in the log..

11/23/2009 01:31:48:154 (PID:01684 ,TID:00006): Failed to retrieve
backupList for the source guest

Any help is appreciated..
--
View this message in context:
http://old.nabble.com/SMVI-2.0-problem-tp26486178p26486178.html
Sent from the Network Appliance - Toasters mailing list archive at
Nabble.com.

SMVI 2.0 problem

2009-11-23T13:37:35Z

ok, scratching my head here...

I just upgraded the new SMVI 2.0 with file level restore.. HURAYY.. Its only been a year, but I guess you cant rush perfection. I was previously running 1.2 and have the typical wait time errors, but for the most part is successful.

Specs:
ESX vshpere 4.0 (non 4i flavor)
SMIV 2.0 (installed on VMWare VIC physical server)
6040's DOT 7.3.11
FC
HP DL380s G5(for now)

problem:
When I try and do a single file restore via self service option, (to and from the same VM guest), I go to select the vm in the restore agent from the guest OS, I press OK. Then I get an error:

Failed to retrieve backupList fro the source guest. And I only have an OK button.

i have tried from multiple guest os'es. Same result.

I looked in the log, and this is just before the popup I get:

at RestoreAgentWCFSvc.RestoreAgent.GetBackupsAndDisks(GuestIdentifier guest, List`1& backupRootedHierarchy, List`1& diskRootedHierarchy, Exception& exFromHyperVisor)
then the error in the log..

11/23/2009 01:31:48:154 (PID:01684 ,TID:00006): Failed to retrieve backupList for the source guest

Any help is appreciated..

RE: Power change 110 to 208v without downtime

2009-11-23T13:20:40Z

It works. I've done it. Gotta check on support.

-----Original Message-----
From: Page, Jeremy <jeremy.page@...>
Sent: Monday, November 23, 2009 12:48 PM
Cc: toasters@... <toasters@...>
Subject: RE: Power change 110 to 208v without downtime

Let us know if it works :-)

________________________________

From: owner-toasters@... [mailto:owner-toasters@...]
On Behalf Of Kevin H. Schoener
Sent: Monday, November 23, 2009 3:25 PM
To: Bill Holland; Suresh Rajagopalan
Cc: toasters@...
Subject: RE: Power change 110 to 208v without downtime

..shouldn't be a problem. The low-side of the Power Supply is the same
for both high-side voltages. So, assuming you're plugging into a 208V
power source on the "new" Power Supplies, it should work fine.

Best Regards,

Kevin

________________________________

From: owner-toasters@... [mailto:owner-toasters@...]
On Behalf Of Bill Holland
Sent: Monday, November 23, 2009 2:59 PM
To: Suresh Rajagopalan
Cc: toasters@...
Subject: Re: Power change 110 to 208v without downtime

I certainly would not be brave enough to try that. Not sure what having
208 on one side and 110 on the other would do, but seems like a
potential for disaster.

On Mon, Nov 23, 2009 at 2:31 PM, Suresh Rajagopalan
<SRajagopalan@...> wrote:

Our filers and shelves are currently on 110v power. We'd like to switch
to 208v, possibly without downtime. I'm thinking of moving each power
supply one by one from 110v to 208v. Are there any issues doing it this
way?

Thanks

Suresh

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.

RE: Power change 110 to 208v without downtime

2009-11-23T12:40:12Z

Let us know if it works J

From: owner-toasters@... [mailto:owner-toasters@...] On Behalf Of Kevin H. Schoener
Sent: Monday, November 23, 2009 3:25 PM
To: Bill Holland; Suresh Rajagopalan
Cc: toasters@...
Subject: RE: Power change 110 to 208v without downtime

..shouldn’t be a problem. The low-side of the Power Supply is the same for both high-side voltages. So, assuming you’re plugging into a 208V power source on the “new” Power Supplies, it should work fine.

Best Regards,

Kevin

From: owner-toasters@... [mailto:owner-toasters@...] On Behalf Of Bill Holland
Sent: Monday, November 23, 2009 2:59 PM
To: Suresh Rajagopalan
Cc: toasters@...
Subject: Re: Power change 110 to 208v without downtime

I certainly would not be brave enough to try that. Not sure what having 208 on one side and 110 on the other would do, but seems like a potential for disaster.

On Mon, Nov 23, 2009 at 2:31 PM, Suresh Rajagopalan <SRajagopalan@...> wrote:

Our filers and shelves are currently on 110v power. We’d like to switch to 208v, possibly without downtime. I’m thinking of moving each power supply one by one from 110v to 208v. Are there any issues doing it this way?

Thanks

Suresh

Re: Power change 110 to 208v without downtime

2009-11-23T12:28:12Z

My educated guess is that you can do this safely and for as long as you
wish. The power supplies are pretty much independent of one another,
and they produce the same output regardless of whether you put 110V or
208V into them -- the filer doesn't know the difference. I have done
this with large HP DL-class servers and have not had any problems.

Suresh Rajagopalan wrote:
> Our filers and shelves are currently on 110v power. We’d like to switch
> to 208v, possibly without downtime. I’m thinking of moving each power
> supply one by one from 110v to 208v. Are there any issues doing it this
> way?