AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20080812135412.45b8cae7@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<john.keiffer@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	BB375AF679D4A34E9CA8DFA650E2B04E0B3BB682@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Tue, 12 Aug 2008 13:54:17 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "John Keiffer" <john.keiffer@onstor.com>
Subject: Re: install
Message-ID: <20080812135417.19292999@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E0B3BB682@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E0B3BB682@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

That's perfect, thanks.  a

On Mon, 11 Aug 2008 18:11:03 -0700 "John Keiffer"
<john.keiffer@onstor.com> wrote:

> Andy,
> 
>  
> 
> Not exactly sure what you are looking for...
> 
>  
> 
> Brian N and I got a system from OPS today, and did an install. It
> went a little something like this:
> 
>  
> 
> 1.	On cougarA we ran through the ICW from the CLI.
> 2.	On cougarB we ran through the FTI from NCM.
> 3.	We checked NTP and found that the second node was not
> syncing with the external NTP server, and instead had synced to
> itself. So we disabled the NTP server and re-added the external NTP
> server, which typically is the work around for kick starting it. When
> both nodes were synced to the external NTP, we also added the sc1 IP
> of cougarA as a backup NTP server on cougarB. This is done as a
> backup in a "Hybrid" cluster config where sc1's are direct connected.
> 4.	We created the cluster by adding cougarB to cougarA.
> 5.	We unplugged the sp ports before we turned on the Cougar.
> We did this because we were trying to see if the filer would reboot
> when we plugged the sp ports in after it was on. This turned out to
> be true. The storage was DotHell. We were not able to see any scsi
> devices. It also appeared that we may have ended up in a reboot loop
> (which may have been caused whenever we tried to re-run scsi
> discovery). There may have also been a problem because both
> controllers were not set the same way for 'loop' or whatever. We may
> have just left the second sp cable unplugged in order to continue.
> Anyway, eventually, we could see the storage. 6.	We then
> labeled luns, added domains, added interfaces, routes, and resolver
> info to the mgmt vsvrs. Then created core and mgmt volumes on both
> systems. 7.	We verified that we could run SGA on both systems
> to the mgmt volume.
> 8.	We verified that we could run SGA to a case number (which
> JP had to add for us first), both with and without using the proxy
> server 'jump.onstor.lab'.
> 9.	We created a volume, added shares, and ran a little
> traffic. 10.	We created a snapshot on the volume.
> 11.	We created a local mirror, ran it, and deleted it. 
> 12.	We created a DMIP mirror, ran it, and deleted it. (this
> was very slow, but I forget why)
> 13.	We check some basic authentication schemes.
> 14.	We tested crashing txrx and fp on cougarA. 
> 
>  
> 
> What else are you interested in hearing about?
> 
>  
> 
> P.S. Anything you want to add Brian?
> 
>  
> 
> Thank you,
> 
> John Keiffer
> 
>  
> 
>  
> 
