Re: clarification about reboots during NDU

-- Fletcher On Feb 2, 2012, at 6:45 PM, Borzenkov, Andrey wrote: > "cf giveback" by itself does not cause extra reboot. Statement is manuals is confusing. > > There could be multiple reboots of A indeed after "cf takeover" to update various firmware. This is entirely transparent as HA pair remains in "A taken over by B" state until A boots far enough to declare itself "ready for giveback". > > ________________________________________ > From: toasters-bounces@teaparty.net [toasters-bounces@teaparty.net] On Behalf Of Fletcher Cocquyt [fcocquyt@stanford.edu] > Sent: Thursday, February 02, 2012 23:24 > To: Parisi, Justin > Cc: toasters@teaparty.net > Subject: Re: clarification about reboots during NDU > > Justin, thanks for the feedback > > What makes step 13 (cf giveback) triggering another reboot of the SAME node A is step 12 reads like that has already been accomplished for node A > > so does node A reboot twice, then when you repeat the procedure, node B reboots twice? > > thanks > -- > Fletcher > > > > On Feb 2, 2012, at 11:20 AM, Parisi, Justin wrote: > > In a takeover/giveback scenario, there are two reboots. > > The first reboot is the takeover. The second reboot is the giveback. > > From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Fletcher Cocquyt > Sent: Thursday, February 02, 2012 1:52 PM > To: toasters@teaparty.netmailto:toasters@teaparty.net > Subject: clarification about reboots during NDU > > > Hi - can someone clarify this from pg 56 of the upgrade guide - > > for instance, if step 12 causes A to "reboot the system using the new firmware and software" > > WHY in step 13 does the cf giveback ALSO "cause system A to reboot with the new system configuration?" > > Are there really 2 reboots ? > > thanks > > > > 12. Enter the following command to reboot the system using the new firmware and software: > > bye > > 13. Choose the option that describes your configuration. > > <image001.png> > <image002.png> > > If FCP or iSCSI... > > Is not in use in system A > > Is in use in system A > > Then when the "Waiting for giveback" message appears on the console of system A... > > Enter the following command at the console of system B: > > cf giveback > > Wait for at least eight minutes to allow host multipathing software to stabilize, then enter the following command at the console of system B: > > cf giveback > > <image001.png> > <image002.png> > <image001.png> > <image002.png> > <image001.png> > <image002.png> > > Attention: The cf giveback command can fail because of open client sessions (such as CIFS sessions), long-running operations, or operations that cannot be restarted (such as tape backup or SyncMirror resynchronization). If the cf givebackcommand fails, terminate any CIFS session or long-running operations gracefully (because the -f option will immediately terminate any CIFS sessions or long-running operations) and then enter the following command (with the -f option): > > cf giveback -f > > For more information about the behavior of the -f option, see the cf(1) man page. > > The command causes system A to reboot with the new system configuration—a Data ONTAP version and any new system firmware and hardware changes—and resume normal operation as a high-availability partner. > > -- > Fletcher Cocquyt > Principal Engineer > Information Resources and Technology (IRT) > Stanford University School of Medicine > <image003.jpg> > > Email: fcocquyt@stanford.edux-msg://993/fcocquyt@stanford.edu > Phone: (650) 724-7485 > > > > >