AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20080604085343.39746a44@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<sandrine.boulanger@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	BB375AF679D4A34E9CA8DFA650E2B04E07845A07@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 4 Jun 2008 08:53:53 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Sandrine Boulanger" <sandrine.boulanger@onstor.com>
Subject: Re: bobcat - cougar migration
Message-ID: <20080604085353.26392356@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E07845A07@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E0A3B9162@onstor-exch02.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E07845A07@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

Unplug the network cable(s), problem solved.

On Wed, 4 Jun 2008 08:17:11 -0700 "Sandrine Boulanger"
<sandrine.boulanger@onstor.com> wrote:

> They won't see the same storage since cables are removed and luns are
> re-zoned, but if they boot off the primary flash that's left, there
> will be IP conflicts. Not sure how to resolve this, since to do a
> system config reset we have to boot up the Bobcats...
> 
> 
> -----Original Message-----
> From: Paul Hammer
> Sent: Tue 6/3/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
> 
