AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20080604095058.08a12958@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<paul.hammer@onstor.com>,<brian.stark@onstor.com>,<larry.scheer@onstor.com>,<tim.gardner@onstor.com>,<sandrine.boulanger@onstor.com>,<jonathan.goldick@onstor.com>,<vikas.saini@onstor.com>,<chris.vandever@onstor.com>,<rendell.fong@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E0A500C61@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 4 Jun 2008 09:51:14 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Paul Hammer" <paul.hammer@onstor.com>
Cc: "Brian Stark" <brian.stark@onstor.com>, "Larry Scheer"
 <larry.scheer@onstor.com>, "Tim Gardner" <tim.gardner@onstor.com>,
 "Sandrine Boulanger" <sandrine.boulanger@onstor.com>, "Jonathan Goldick"
 <jonathan.goldick@onstor.com>, "Vikas Saini" <vikas.saini@onstor.com>,
 "Chris Vandever" <chris.vandever@onstor.com>, "Rendell Fong"
 <rendell.fong@onstor.com>
Subject: Re: bobcat - cougar migration
Message-ID: <20080604095114.730fd5ed@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E0A500C61@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E0A500C58@onstor-exch02.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E0A500C61@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Wed, 4 Jun 2008 09:40:28 -0700 "Paul Hammer"
<paul.hammer@onstor.com> wrote:

> Thanks Brian. So looks like we just need to figure out and document
> the process for the IP changes.

Unplug the network cable(s); system config reset.

 _____________________________________________
> From: Brian Stark 
> Sent: 2008-06-04 09:37
> To: Paul Hammer; Larry Scheer; Tim Gardner; Sandrine Boulanger;
> Jonathan Goldick; Andy Sharp; Vikas Saini; Chris Vandever
> Cc: Rendell Fong
> Subject: RE: bobcat - cougar migration
> 
> We are NOT migrating MAC addresses from Bobcat to Cougar.  We had
> originally planned to migrate the MAC address so that the top slot
> Cougar motherboard would have the same MAC as the Bobcat, but we then
> decided not to do this so that there was no differentiation between
> migrating Bobcats to top slot or bottom slot on Cougar.  
> 
> Because of that, Cougar and Bobcat will have no MAC address conflicts,
> and therefore no WWN conflicts.  For Cougar, both slots will need to
> have storage re-provisioned if it's taking storage from Bobcat.  Also,
> Bobcat can be used elsewhere, if necessary, once IP addresses are
> changed on the IP links.
> 
> 
> Brian
> 
> 
> 	_____________________________________________ 
> 	From: 	Paul Hammer  
> 	Sent:	Tuesday, June 03, 2008 10:28 PM
> 	To:	Larry Scheer; Tim Gardner; Sandrine Boulanger;
> Brian Stark; Jonathan Goldick; Andy Sharp; Vikas Saini; Chris Vandever
> 	Cc:	Rendell Fong
> 	Subject:	RE: bobcat - cougar migration
> 
> 	Agree with you Tim, but this is still the worry I have, no
> trade in and the want to re-provision.
> 
> 	_____________________________________________
> 	From: Larry Scheer 
> 	Sent: 2008-06-03 22:26
> 	To: Tim Gardner; Paul Hammer; Sandrine Boulanger; Brian Stark;
> Jonathan Goldick; Andy Sharp; Vikas Saini; Chris Vandever
> 	Cc: Rendell Fong
> 	Subject: RE: bobcat - cougar migration
> 
> 	Now that Tim mentions it forgot about the MAC address change
> that needs to happen on the bobcat side. 
> 	That can be done with seep but who is going to provide the new
> MAC addresses?
> 
> 	Its late, I need a break..
> 
> 	_____________________________________________
> 	From: Tim Gardner 
> 	Sent: Tuesday, June 03, 2008 10:23 PM
> 	To: Paul Hammer; Sandrine Boulanger; Larry Scheer; Brian
> Stark; Jonathan Goldick; Andy Sharp; Vikas Saini; Chris Vandever
> 	Cc: Rendell Fong
> 	Subject: RE: bobcat - cougar migration
> 
> 	Then they shouldn't be doing a migration. They should just
> deploy the cougars as new systems and
> 	provision new storage for them. Migration is for when they are
> trading in the bobcats.
> 	Really bad idea to have multiple systems with the same MAC
> addresses.
> 
> 	_____________________________________________
> 	From: Paul Hammer 
> 	Sent: Tuesday, June 03, 2008 9:52 PM
> 	To: Sandrine Boulanger; Larry Scheer; Brian Stark; Tim
> Gardner; Jonathan Goldick; Andy Sharp; Vikas Saini; Chris Vandever
> 	Cc: Rendell Fong
> 	Subject: RE: bobcat - cougar migration
> 
> 	To prevent the Bobcat from ever seeing the Cougar and it's
> storage after the migration (if they wish re-provision the bobcat)
> what do we need to do? 
> 
> 	Should we reprogram the MAC on the Bobcats, wipe the flashes,
> etc ...? I guess I am asking now how can the customer re-provision
> their bobcats post migration that will ensure that we do not have
> both bobcats and cougars seeing the same storage as theirs
> 
> 	_____________________________________________
> 	From: Sandrine Boulanger 
> 	Sent: 2008-06-03 16:08
> 	To: Larry Scheer; Paul Hammer; Brian Stark; Tim Gardner;
> Jonathan Goldick; Andy Sharp; Vikas Saini; Chris Vandever
> 	Cc: Rendell Fong
> 	Subject: RE: bobcat - cougar migration
> 
> 	
> 
> 	_____________________________________________
> 	From: Larry Scheer 
> 	Sent: Tuesday, June 03, 2008 4:01 PM
> 	To: Sandrine Boulanger; Paul Hammer; Brian Stark; Tim Gardner;
> Jonathan Goldick; Andy Sharp; Vikas Saini; Chris Vandever
> 	Cc: Rendell Fong
> 	Subject: RE: bobcat - cougar migration
> 
> 	The bobcat system can't be powered up when the migration is
> done because the new cougar would have all of the IP addresses and
> there would be an IP address conflict when the cougar reboots after
> the migration.
> 	> correct, this is just a fallback, and in that case the
> 	> Cougar
> would have to be powered off.
> 
> 	Does the migration procedure instruct the user to do a system
> config copy and then pull the secondary flash from the bobcat? 
> 	> yes. As far as I remember
> 
> 	The important  parts are the bobcat is off line (preferably
> powered off during the migration process) and the correct flash is
> installed in the cougar. The customer should be made aware (have the
> expectation) that the compact flash used in the migration process is
> useless in their bobcats.
> 	> we can add that statement to the documentation.
> 
> 	Larry
> 
> 
> 	_____________________________________________
> 	From: Sandrine Boulanger 
> 	Sent: Tuesday, June 03, 2008 3:44 PM
> 	To: Larry Scheer; Paul Hammer; Brian Stark; Tim Gardner;
> Jonathan Goldick; Andy Sharp; Vikas Saini; Chris Vandever
> 	Cc: Rendell Fong
> 	Subject: RE: bobcat - cougar migration
> 
> 	That does not matter. The flash that would be used for the
> migration would be the secondary Bobcat flash. Primary flash would
> still be working if they would run into problems and go back. Just
> have to re-zone all the luns back.
> 
> 	_____________________________________________
> 	From: Larry Scheer 
> 	Sent: Tuesday, June 03, 2008 3:41 PM
> 	To: Paul Hammer; Brian Stark; Tim Gardner; Jonathan Goldick;
> Andy Sharp; Sandrine Boulanger; Vikas Saini; Chris Vandever
> 	Cc: Rendell Fong
> 	Subject: FW: bobcat - cougar migration
> 
> 	Since we were talking about this in the meeting; the CF used
> for the migration is no longer usable in the original Bobcat.
> 
> 	See Rendell's results bellow.
> 
> 	By the way Rendell's boot problem was the load_opts setting in
> his SSC prom environment.
> 
> 	Later,
> 
> 	Larry
> 	_____________________________________________
> 	From: Rendell Fong 
> 	Sent: Tuesday, June 03, 2008 3:34 PM
> 	To: Larry Scheer
> 	Subject: bobcat - cougar migration
> 
> 	Larry,
> 
> 	It appears that after doing the migration, Bobcat can no
> longer recognize the flash that Bobcat used since the migration
> script looks like it changes the flash filesystem type.
> 
> 	Rendell
> 
> 
> 	Eng59 console during bootup:
> 
> 	rootdev=0x410 rrootdev=0x1210 rawdev=0x1212
> 	filesystem type 0 not known.. assuming ffs
> 	panic: cannot mount root
> 	Saved crashdump.
> 
> 	dumping to dev 411, offset 8
> 	dump not yet implementedSystem restart.
> 
> 	PMON CPU 00000000 Initializing. Standby...
> 	EXCEPTIONPC=00000000 CONFIG=005264b0 STATUS=00400000
> 	Setting up SDRAM controllers
> 	R9K MEMORY SIZE=40000000
> 	SDM  REG=00000047
> 	SDT  REG=283f8482
