"Borzenkov, Andrey" <andrey.borzenkov@ts.fujitsu.com> 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.net<mailto: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.net<mailto: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.edu<x-msg://993/fcocquyt@stanford.edu>
Phone: (650) 724-7485







Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters