• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (8)

1 AnthonyEnglish commented Permalink

Good story, Chris. And multibos is so easy to use, it was definitely worth it. <div>&nbsp;</div> Were they virtual of physical FC adapters on the client? It looks like they were physical (fcs0, fcs1) dedicated to the AIX LPAR, so where did the virtual FC adapters come into it? <div>&nbsp;</div> Sounds a bit like the queue_depth for virtual SCSI disks. Change it on the VIO Server first, then on the client, or else the I/O bottleneck would just get moved upstream to the VIOS, I suppose.

2 cggibbo commented Permalink

The adapters are virtual.... <div>&nbsp;</div> fcs0 Available 20-T1 Virtual Fibre Channel Client Adapter <br /> fcs1 Available 30-T1 Virtual Fibre Channel Client Adapter <div>&nbsp;</div> <div>&nbsp;</div> Similar to the queue_depth problem, but the impact is far worse! :)

3 AnthonyEnglish commented Permalink

OK, thanks. <div>&nbsp;</div> Just curious. The boot disk was still intact. Could this be handled via the SMS menus somehow? For example, by mapping the SAN LUN to a new set of virtual FC adapters which would have the default max_xfer_size? Or maybe booting off media and importing the rootvg, then changing the attribute back to match the VIOS FC adapters, and then rebooting? <div>&nbsp;</div> Or without an alternate boot image (multibos or alt_disk_copy) would there be no other option than a restore from a mksysb backup?

4 John.Wright commented Permalink

A lesson for all of us here. As soon as I started reading this I thought "I bet the change wasn't reflected on the VIOS" and, true enough, it wasn't. <div>&nbsp;</div> I got caught out by this earlier this year. Changed some FC adapter settings (vfc) through to an XIV but didn't change anything on the VIOS. I *think* I shut the LPAR down, made the change on the VIOS, and restarted the LPAR. <div>&nbsp;</div> Multibos is brilliant though. Underused too. <div>&nbsp;</div> Great article, Chris.

5 Morten_Torstensen commented Permalink

Well, or he could actually do it with no boot at all, assuming he has at least two paths to each disk. Just do the "chdev ... -P", then "rmdev -Rl fcs0" to set it all defined on one leg and a "cfgmgr -l fcs0". If it comes up it is ok, if not it is not. Server side VIOS adapters must be same or bigger, for command elements and max transfer size. <div>&nbsp;</div> You can change the VIOS adapter in the same way, online using path redundancy.

6 cggibbo commented Permalink

Indeed. I made some similar comments in a previous post. Which is why I didn't repeat them in this post... <div>&nbsp;</div> https://www.ibm.com/developerworks/mydeveloperworks/blogs/cgaix/entry/checking_num_cmd_elems_for_vfc_adapters_with_kdb1?lang=en

7 Federico_Sciarretta commented Permalink

Hello , just a question, I wondering if is possible to sync the config files after multibos,for example, files as /etc/passwd automatically. <br /> Thank you

8 stephane_mielvaque commented Permalink

Great explanation of an underuse tools .. <br /> When booting on the standby instance, have you a method to update the original instance ? <br /> Example : update of sys0 or as your example update max_xfer_size on the original instance. <br /> To make the standy instance as the original instance is there another way that remove multibos (multibos -R) and rename each LV without prefixe "bos_" with chlv ( ex: bos_hd9 to hd9) ? <br /> thanks for your interesting blog !

Add a Comment Add a Comment