X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C7DDF0.881A2854@onstor-exch02.onstor.net>; Mon, 13 Aug 2007 13:25:54 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: Change management IP address
Date: Mon, 13 Aug 2007 13:25:54 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E03E9A2AA@onstor-exch02.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E04FA785F@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Change management IP address
Thread-Index: AcfbdOkHtZm3uOISR0G9W68jRkOyPQCafdwwAAB331AAA3YLtgAADyPQAAAtJqA=
From: "Chris Vandever" <chris.vandever@onstor.com>
To: "Eric Barrett" <eric.barrett@onstor.com>,
	"Tim O'Callaghan" <tim.ocallaghan@onstor.com>,
	"Sandrine Boulanger" <sandrine.boulanger@onstor.com>,
	"John Culp" <john.culp@onstor.com>,
	"Rich LaReau" <rich.lareau@onstor.com>,
	"dl-cstech" <dl-cstech@onstor.com>

Minor correction: if you delete a node that has vsvrs from the cluster
it will ask you if you really want to delete it.  However, it's a bad
idea to rely upon that, because if vsvrs failover to a node being
deleted between the time you do a "cluster delete nasgateway" and the
time you do a "cluster commit" the vsvrs will simply be deleted along
with the node.

Yes, there's a defect already.  :(

Tim, there's nothing I can recall on 3.0 that would change the behavior
with respect to cluster.conf.  If you hit it again, please get the elogs
(info level, if possible), cluster database, and cluster.conf file for
me.  We've tried to make sure we make an elog entry whenever
cluster.conf or the cluster database is intentionally cleared.  Thanks.

ChrisV

-----Original Message-----
From: Eric Barrett=20
Sent: Monday, August 13, 2007 2:15 PM
To: Tim O'Callaghan; Sandrine Boulanger; John Culp; Rich LaReau;
dl-cstech
Subject: RE: Change management IP address

Another gotcha is that all vsvrs need to be moved to the original
cluster node which isn't being removed.  If you delete a node from the
cluster, any vsvr currently hosted on it is also deleted
unconditionally.
=20

-----Original Message-----
From: Tim O'Callaghan=20
Sent: Monday, August 13, 2007 2:12 PM
To: Sandrine Boulanger; John Culp; Rich LaReau; dl-cstech
Subject: Re: Change management IP address



I have managed this by reducing the system to a single node cluster with
all the vServers then reintroducing the other filers.

Warning though - when I went through the same process with 3.0.0.0 I
lost the cluster config on the master system - might have been a mistake
on my part - so I'm waiting for the next instance to be sure.

Tim
Tim.OCallaghan@onstor.com

M:+44 7767435472
--------------------------
Sent using BlackBerry


-----Original Message-----
From: Sandrine Boulanger
To: John Culp; Rich LaReau; dl-cstech
Sent: Mon Aug 13 12:33:45 2007
Subject: RE: Change management IP address

John, you can only do this for a single node cluster. As soon as the
number of nodes is 2 or more, the ssc ips cannot be modified.

_____________________________________________
From: John Culp=20
Sent: Monday, August 13, 2007 12:22 PM
To: Rich LaReau; dl-cstech
Subject: RE: Change management IP address

I know that if you remove the IP address from one of the SC ports you
can get the wonderful PM SESSION DOWN message.

In the past I have use the "interface modify sc2 -d x.x.x.x" followed by
"interface modify sc2 -a x.x.x.x/subnet" and it work.  I have not tried
it on sc1.  I am sure it would work. =20

 BUT I did not say supported.  :-)

John Culp=20

Sr. System Engineer=20
940-239-7489 Office=20
972-523-4287 Cell=20
john.culp@onstor.com=20



_____________________________________________=20
From: 	Rich LaReau =20
Sent:	Friday, August 10, 2007 12:36 PM
To:	dl-cstech
Subject:	Change management IP address


A customer is moving their network to new IP space, and would like to
change the management addresses on their filers to match.  The only
reference I could find was this very scary-looking process here:

http://wiki/wiki/Reconfigure_management_ports_IP_addresses

Is this still the case for 3.0?  Are there any other methods-- maybe
getting the database and hand-editing it to make the desired changes? =20

Thanks,
Rich

