Ucs

As I wrote before about enabling multipathing for the AutoYaST installation it’s about time I write this one here. Sadly AutoYaST needs a little push in the right direction (as to where to actually put the root device), so here’s part of my AutoYaST profile for such a Cisco blade: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 <profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns"> <bootloader> <device_map config:type="list"> <device_map_entry> <firmware>hd0</firmware> <linux>/dev/sda</linux> </device_map_entry> </device_map> </bootloader> <partitioning config:type="list"> <drive> <device>/dev/sda</device> </drive> </partitioning> <scripts> <pre-scripts config:type="list"> <script> <debug config:type="boolean">false</debug> <feedback config:type="boolean">false</feedback> <filename>config-ucs.sh</filename> <interpreter>shell</interpreter> <source><![CDATA[ cat /tmp/profile/autoinst.xml | sed "s,/dev/sda,/dev/mapper/`/sbin/multipath -ll | grep dm-0 | cut -d -f1`," > /tmp/profile/modified.xml ]]> </source> </script> </pre-scripts> <chroot-scripts config:type="list"> <script> <chrooted config:type="boolean">true</chrooted> <debug config:type="boolean">true</debug> <feedback config:type="boolean">true</feedback> <filename>config-ucs-chroot.sh</filename> <interpreter>shell</interpreter> <location>http://install.home.barfoo.org/autoyast/scripts/config-ucs-chroot.sh</location> </script> </chroot-scripts> </scripts> <software> <packages config:type="list"> <package>multipath-tools</package> </packages> </software> </profile> Now, the profile addition takes care of the placement of the root-device now (simply parses multipath -ll) and adjusts the pulled profile accordingly ( /tmp/profile/modified.xml), which AutoYaST then re-reads. ...

As I mentioned before, we’re starting to utilize Boot-from-SAN as a means to strip the blades of their local disk. As the title says, after trying a manual installation of SLES 11.1 via CD/HTTP I wanted to automate the process, in order to get a reproducible, consistent installation method. As you might have figured, AutoYaST doesn’t have any built in support for configuring multipathing (hey, that’s what Novell says here). Now, they also provide a comprehensive how-to on how to “add” this to your AutoYaST, using a DUD (or D river U pdate D isk). ...

Well, another day - another UCS error. Out of the blue, one of our chassis started displaying that one PSU had failed, however the UCS was showing no PSU had failed 🤷 Well, as it turns out - this is yet another known bug in 2.0.2(r). You’ll either have to unplug and plug all the power cables (that’s four) in a maintainance window - or simply change the Equipment Power Policy (found in the Root of your UCS, tab Policy) ...

Well, we’ve been battling with a KVM bug in our UCS installation, that’s been driving me (and apparently the Cisco L3 support and development) nuts. But lets back up a bit. If you’ve worked with UCS before, once you open up the KVM console you’ll see the KVM and a shortcut commands (Shutdown, Reset) and another tab that allows you to mount virtual media. Once you open it up, it should look like this: ...

Well, I have yet another weird UCS problem. I have a single blade, that has trouble with it’s primary fabric attachment. The problem get’s even more weird, if you look at the details. After looking at the IO modules, the error doesn’t become any clearer: So far, I have tried nearly everything. I’ve tried resetting the active and passive Connectivity of the vNIC, I tried resetting the DCE adapter for the vNIC, but nothing. I even tried resetting the vHBA that’s associated with this fabric, but that didn’t result to anything. Not even the usual flogi (fibre channel login) errors, that you get when either booting/resetting the blade. ...

Well, I recently had yet another UCS display/I2C communication problem. Somehow one of my chassis’ started to think, that the power redundancy was lost. After looking at it a bit deeper, it seems only the GUI or the chassis did notice this power glitch: As you can see, all PSU’s still have power. Now, since I had a big maintainance window the last weekend anyhow (and I spent ~14 hours at work), I decided to restart the IO modules in that chassis. And guess what: The error is gone! Another weird I2C communication issue with the firmware release 2.0.2 …

Well, after I scripted the installation the other day, I tried installing SLES11.1-Updates to the freshly installed systems. Guess what ? The thing broke. Initially (it was late Friday afternoon - like 6 PM - before my one week vacation) I didn’t have much time to debug the issue, so I sat down last week and looked at the issue. During the installation, when first starting multipath via command line, the scsi-mpatha device appears, and each and every occurance of this is subsequentially being used (and other stuff replaced by this actually) during the whole installation phase. ...