I talked about the open-iscsi initiator in a previous post, and briefly touched on debugging problems. If you want to get additional debugging data for the iscsid daemon, you can add the “-d 8” option to the iscsi initialization file:
$ less /etc/init.d/iscsid
start()
{
echo -n $"Turning off network shutdown. "
# we do not want iscsi or network to run during system shutdown
# incase there are RAID or multipath devices using
# iscsi disks
chkconfig --level 06 network off
rm /etc/rc0.d/*network
rm /etc/rc6.d/*network
echo -n $"Starting iSCSI daemon: "
modprobe -q iscsi_tcp
modprobe -q ib_iser
daemon iscsid -d 8
RETVAL=$?
echo
[ $RETVAL -eq 0 ] || return
touch /var/lock/subsys/iscsid
success
echo
}
This will cause the daemon to write a bunch of debugging data to the syslog logs, which you can then use to isolate problems.
While reading through the Redhat Oracle 10G best practices document, I came across this gem:
“In virtualized environments, it is often detrimental to schedule I/O at both the host and guest layers. If multiple guests access storage on a file system or block devices managed by the host operating system, the host may be able to schedule I/O more efficiently because it alone is aware of requests from all guests and knows the physical layout of storage, which may not map linearly to the guests’ virtual storage. Red Hat Enterprise Linux 4 and Red Hat Enterprise Linux 5 guests can use the noop I/O scheduler to allow the host to optimize I/O requests.”
This makes complete sense, and I am going to have to test out the noop I/O scheduler in my lab this weekend. I’m curious how many folks run the default I/O scheduler in their Xen or KVM guests, and are actually hindering I/O performance by doing so.
I’ve written about the Emulex emlxadm utility in the past, and how it can be used to view and manage adapters. In addition to viewing stats and configuration data, you can also use emlxadm to view and update firmware. To view the current firmware version, you can type “get_fw_rev” into the emlxadm shell:
emlxadm> **get_fw_rev**
Firmware revision: LP10000DC 1.81a1
If the firmware needs to be updated, you can run download_fcode with the path to the firmware image:
emlxadm> **download_fcode
/export/home/matty/emulex/firmware/1.92a1/td192a1.all**
Image Components: NOP type
AWC file: KERN: version=ff801416, 1.40a6
DWC file: SLI2: version=07831991, 1.92a1
DWC prog: TEST: version=00f51051, 1.01a1
DWC prog: STUB: version=02881991, 1.92a1
DWC prog: SLI1: version=06831991, 1.92a1
DWC prog: SLI2: version=07831991, 1.92a1
Current: Fcode: none
New: Fcode: none 376064 (0x5bd00) bytes
Are you sure you want to download this image? (y or n): y
Downloading...
Result: Operation successful.
Done.
*NOTE: The new FCode version will not be activated until the host
is rebooted or a DR operation is performed on the adapter.
emlxadm> **get_fw_rev**
Firmware revision: LP10000DC 1.92a1
This post is a reference for myself, and I take ZERO responsibility for botched firmware updates. As with all information on this blog, use this information at your own risk (no warranties of any sort are provided).
I purchased a used Brocade 3200 for my home lab, and needed to update the network information to allow myself to login remotely. To view the existing network configuration, I serial consoled in and ran the ipAddrShow command:
Switch:admin> **ipAddrShow**
Ethernet IP Address: 10.1.1.48
Ethernet Subnetmask: 255.255.255.0
Fibre Channel IP Address: none
Fibre Channel Subnetmask: none
Gateway Address: 10.1.1.1
Once I checked the existing settings, I ran the ipAddrSet command to update the network settings:
Switch:admin> **ipAddrSet**
Ethernet IP Address [10.192.40.148]: 192.168.1.2
Ethernet Subnetmask [255.255.240.0]: 255.255.255.0
Fibre Channel IP Address [none]:
Fibre Channel Subnetmask [none]:
Gateway Address [10.192.47.254]: 192.168.1.1
I really dig Brocade, and their command set is simple and easy to use.
If you are using the Linux dm-multipath package to provide mulit-pathing in clustered environments, it is super important that the dev-mapper devices show up with the same name on each node. One way to achieve this is through multipath.conf aliases, which allow you to assign a name to a mapper device based on it’s WWID:
multipath {
wwid 3600144f049e0361000000c29877ac600
alias iscsidisk1
path_grouping_policy failover
path_selector "round-robin 0"
failback immediate
}
If you want to stick with mpath[0-9]+ names, you can propagate the /var/lib/multipath/bindings file to each node in the cluster. This file contains the name of each mpath device, along with the WWID that is assigned to it:
$ cat /var/lib/multipath/bindings
# Multipath bindings, Version : 1.0
# NOTE: this file is automatically maintained by the multipath program.
# You should not need to edit this file in normal circumstances.
#
# Format:
# alias wwid
#
mpath0 3600144f049e0360f00000c29877ac600
mpath1 3600144f049e0361000000c29877ac600
mpath2 3600144f049e0361100000c29877ac600
The device-mapper is pretty sweet, and the price tag (free) is even better!