IC SunsetThe developerWorks Connections platform will be sunset on December 31, 2019. On January 1, 2020, this blog will no longer be available. More details available on our FAQ.

Comments (8)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (8)

stephane_mielvaque commented June 12 2013 Comment Permalink
More...
View Full Thread (${0} replies)

Great explanation of an underuse tools .. When booting on the standby instance, have you a method to update the original instance ? Example : update of sys0 or as your example update max_xfer_size on the original instance. 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) ? thanks for your interesting blog !

Federico_Sciarretta commented Apr 5 2013 Comment Permalink
More...
View Full Thread (${0} replies)

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

cggibbo commented Nov 28 2012 Comment Permalink
More...
View Full Thread (${0} replies)

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

Morten Torstensen commented Nov 28 2012 Comment Permalink
More...
View Full Thread (${0} replies)

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. You can change the VIOS adapter in the same way, online using path redundancy.

John.Wright commented Nov 4 2012 Comment Permalink
More...
View Full Thread (${0} replies)

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. 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. Multibos is brilliant though. Underused too. Great article, Chris.

AnthonyEnglish commented Nov 1 2012 Comment Permalink
More...
View Full Thread (${0} replies)

OK, thanks. 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? Or without an alternate boot image (multibos or alt_disk_copy) would there be no other option than a restore from a mksysb backup?

cggibbo commented Nov 1 2012 Comment Permalink
More...
View Full Thread (${0} replies)

The adapters are virtual.... fcs0 Available 20-T1 Virtual Fibre Channel Client Adapter fcs1 Available 30-T1 Virtual Fibre Channel Client Adapter Similar to the queue_depth problem, but the impact is far worse! :)

AnthonyEnglish commented Nov 1 2012 Comment Permalink
More...
View Full Thread (${0} replies)

Good story, Chris. And multibos is so easy to use, it was definitely worth it. 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? 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.