text:
Red Hat Enterprise Linux 5
For Red Hat Enterprise Linux 5
This document outlines the different procedures involved in reconfiguring storage devices while the system is running. The document currently addresses iSCSI and Fibre Channel interconnects. Other interconnects may be added in future versions of this document.
- 1. Introduction
- 2. Fibre Channel
- 3. iSCSI
- 4. Persistent Naming
- 5. Removing a Storage Device
- 6. Removing a Path to a Storage Device
- 7. Adding a Storage Device or Path
- 8. Technology Preview: Fibre-Channel Over Ethernet Interface
- 9. Scanning Storage Interconnects
- 10. iSCSI Discovery Configuration
- 11. Configuring iSCSI Offload and Interface Binding
- 12. Scanning iSCSI Interconnects
- 13. Logging In to an iSCSI Target
- 14. Online Logical Units
- 15. Changing the Read/Write State of an Online Logical Unit
- 16. Adding/Removing a Logical Unit Through rescan-scsi-bus.sh
- 17. Modifying Link Loss Behavior
- 18. Controlling the SCSI Command Timer and Device Status
- 19. Troubleshooting
- A. Revision History
- Index
It is often desirable to add, remove or re-size storage devices while the operating system is running, and without rebooting. This manual outlines the procedures that may be used to reconfigure storage devices on Red Hat Enterprise Linux 5 host systems while the system is running. It covers iSCSI and Fibre Channel storage interconnects; other interconnect types may be added it the future.
The Online Storage Reconfiguration guide focuses on adding, removing, modifying, and monitoring storage devices. It does not discuss the Fibre Channel or iSCSI protocols in detail. For more information about these protocols, refer to other documentation.
This manual assumes that you have advanced working knowledge of Red Hat Enterprise Linux 5, along with first-hand experience in managing storage devices in Linux. Before consulting this book, verify if your host bus adapter vendor or hardware vendor have their own documentation. It is recommended that you consult such documents in conjunction with this manual.
This manual makes reference to various
sysfs objects. Red Hat advises that the
sysfs object names and directory structure are subject to change in major Red Hat Enterprise Linux 5 releases. This is because the upstream Linux kernel does not provide a stable internal API. For guidelines on how to reference
sysfs objects in a transportable way, refer to the document
Documentation/sysfs-rules.txt in the kernel source tree for guidelines.
Online storage reconfiguration must be done carefully. System failures or interruptions during the process can lead to unexpected results. Red Hat advises that you reduce system load to the maximum extent possible during the change operations. This will reduce the chance of I/O errors, out-of-memory errors, or similar errors occurring in the midst of a configuration change. The following sections provide more specific guidelines regarding this.
In addition, Red Hat recommends that you back up all data before performing online storage reconfiguration.
This manual uses several conventions to highlight certain words and phrases and draw attention to specific pieces of information.
In PDF and paper editions, this manual uses typefaces drawn from the Liberation Fonts set. The Liberation Fonts set is also used in HTML editions if the set is installed on your system. If not, alternative but equivalent typefaces are displayed. Note: Red Hat Enterprise Linux 5 and later include the Liberation Fonts set by default.
Four typographic conventions are used to call attention to specific words and phrases. These conventions, and the circumstances they apply to, are as follows.
Mono-spaced Bold
Used to highlight system input, including shell commands, file names and paths. Also used to highlight keys and key combinations. For example:
To see the contents of the file
my_next_bestselling_novelin your current working directory, enter the
cat my_next_bestselling_novelcommand at the shell prompt and press Enter to execute the command.
The above includes a file name, a shell command and a key, all presented in mono-spaced bold and all distinguishable thanks to context.
Key combinations can be distinguished from an individual key by the plus sign that connects each part of a key combination. For example:
Press Enter to execute the command.Press Ctrl+Alt+F2 to switch to a virtual terminal.
The first example highlights a particular key to press. The second example highlights a key combination: a set of three keys pressed simultaneously.
If source code is discussed, class names, methods, functions, variable names and returned values mentioned within a paragraph will be presented as above, in
mono-spaced bold. For example:
File-related classes include
filesystemfor file systems,
filefor files, and
dirfor directories. Each class has its own associated set of permissions.
Proportional Bold
This denotes words or phrases encountered on a system, including application names; dialog-box text; labeled buttons; check-box and radio-button labels; menu titles and submenu titles. For example:
Choose Mouse Preferences. In the Buttons tab, select the Left-handed mouse check box and click to switch the primary mouse button from the left to the right (making the mouse suitable for use in the left hand).→ → from the main menu bar to launchTo insert a special character into a gedit file, choose → → from the main menu bar. Next, choose → from the Character Map menu bar, type the name of the character in the Search field and click . The character you sought will be highlighted in the Character Table. Double-click this highlighted character to place it in the Text to copy field and then click the button. Now switch back to your document and choose → from the gedit menu bar.
The above text includes application names; system-wide menu names and items; application-specific menu names; and buttons and text found within a GUI interface, all presented in proportional bold and all distinguishable by context.
Mono-spaced Bold Italic
Proportional Bold Italic
Whether mono-spaced bold or proportional bold, the addition of italics indicates replaceable or variable text. Italics denotes text you do not input literally or displayed text that changes depending on circumstance. For example:
To connect to a remote machine using ssh, type
sshat a shell prompt. If the remote machine is
example.comand your username on that machine is john, type
ssh email@example.com
mount -o remountcommand remounts the named file system. For example, to remount the
/homefile system, the command is
mount -o remount /home.To see the version of a currently installed package, use the
rpm -qcommand. It will return a result as follows:
Note the words in bold italics above: username, domain.name, file-system, package, version and release. Each word is a placeholder, either for text you enter when issuing a command or for text displayed by the system.
Aside from standard usage for presenting the title of a work, italics denotes the first use of a new and important term. For example:
Publican is a DocBook publishing system.
Terminal output and source code listings are set off visually from the surrounding text.
Output sent to a terminal is set in
mono-spaced roman and presented thus:
books Desktop documentation drafts mss photos stuff svn books_tests Desktop1 downloads images notes scripts svgs
Source-code listings are also set in
mono-spaced roman but add syntax highlighting as follows:
static int kvm_vm_ioctl_deassign_device(struct kvm *kvm,
struct kvm_assigned_pci_dev *assigned_dev)
int r = 0;
struct kvm_assigned_dev_kernel *match;
match = kvm_find_assigned_dev(&kvm->arch.assigned_dev_head,
if (!match) {
printk(KERN_INFO "%s: device hasn't been assigned before, "
"so cannot be deassigned\n", __func__);
r = -EINVAL;
goto out;
kvm_deassign_device(kvm, match);
kvm_free_assigned_device(kvm, match);
return r;
Finally, we use three visual styles to draw attention to information that might otherwise be overlooked.
Notes are tips, shortcuts or alternative approaches to the task at hand. Ignoring a note should have no negative consequences, but you might miss out on a trick that makes your life easier.
Important boxes detail things that are easily missed: configuration changes that only apply to the current session, or services that need restarting before an update will apply. Ignoring a box labeled "Important" will not cause data loss but may cause irritation and frustration.
Warnings should not be ignored. Ignoring warnings will most likely cause data loss.
If you experience difficulty with a procedure described in this documentation, visit the Red Hat Customer Portal at http://access.redhat.com. Through the customer portal, you can:
- search or browse through a knowledgebase of technical support articles about Red Hat products.
- submit a support case to Red Hat Global Support Services (GSS).
- access other product documentation.
Red Hat also hosts a large number of electronic mailing lists for discussion of Red Hat software and technology. You can find a list of publicly available mailing lists at https://www.redhat.com/mailman/listinfo. Click on the name of any mailing list to subscribe to that list or to access the list archives.
If you find a typographical error in this manual, or if you have thought of a way to make this manual better, we would love to hear from you! Please submit a report in Bugzilla: http://bugzilla.redhat.com/ against the product Red_Hat_Enterprise_Linux.
When submitting a bug report, be sure to mention the manual's identifier: Online_Storage_Reconfiguration_Guide
If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, please include the section number and some of the surrounding text so we can find it easily.
This section discusses the Fibre Channel API, native Red Hat Enterprise Linux 5 Fibre Channel drivers, and the Fibre Channel capabilities of these drivers.
Below is a list of
/sys/class/ directories that contain files used to provide the userspace API. In each item, host numbers are designated by
, bus numbers are
, targets are
, logical unit numbers (LUNs) are
, and remote port numbers are
If your system is using multipath software, Red Hat recommends that you consult your hardware vendor before changing any of the values described in this section.
- Transport:
port_id— 24-bit port ID/address
node_name— 64-bit node name
port_name— 64-bit port name
- Remote Port:
dev_loss_tmo— number of seconds to wait before marking a link as "bad". Once a link is marked bad, IO running on its corresponding path (along with any new IO on that path) will be failed.The default
dev_loss_tmovalue varies, depending on which driver/device is used. If a Qlogic adapter is used, the default is 35 seconds, while if an Emulex adapter is used, it is 30 seconds. The
dev_loss_tmovalue can be changed via the
scsi_transport_fcmodule parameter
dev_loss_tmo, although the driver can override this timeout value.The maximum
dev_loss_tmovalue is 600 seconds. If
dev_loss_tmois set to zero or any value greater than 600, the driver's internal timeouts will be used instead.
fast_io_fail_tmo— length of time to wait before failing IO executed when a link problem is detected. IO that reaches the driver will fail. If IO is in a blocked queue, it will not be failed until
dev_loss_tmoexpires and the queue is unblocked.
- Host:
Red Hat Enterprise Linux 5 ships with the following native fibre channel drivers:
Table 1, "Fibre-Channel API Capabilities" describes the different fibre-channel API capabilities of each native Red Hat Enterprise Linux 5 driver. X denotes support for the capability.
Table 1. Fibre-Channel API Capabilities
This section describes the iSCSI API and the
iscsiadm utility. Before using the
iscsiadm utility, install the
iscsi-initiator-utils package first; to do so, run
yum install iscsi-initiator-utils.
In addition, the iSCSI service must be running in order to discover or log in to targets. To start the iSCSI service, run
service iscsi start
To get information about running sessions, run:
iscsiadm -m session -P 3
This command displays the session/device state, session ID (sid), some negotiated parameters, and the SCSI devices accessible through the session.
For shorter output (for example, to display only the sid-to-node mapping), run:
iscsiadm -m session -P 0
iscsiadm -m session
These commands print the list of running sessions with the format:
target_ip:port,target_portal_group_tag proper_target_name
For example:
iscsiadm -m session
tcp [2] 10.15.84.19:3260,2 iqn.1992-08.com.netapp:sn.33615311 tcp [3] 10.15.85.19:3260,3 iqn.1992-08.com.netapp:sn.33615311
For more information about the iSCSI API, refer to
The operating system issues I/O to a storage device by referencing the path that is used to reach it. For SCSI devices, the path consists of the following:
- PCI identifier of the host bus adapter (HBA)
- channel number on that HBA
- the remote SCSI target address
- the Logical Unit Number (LUN)
This path-based address is not persistent. It may change any time the system is reconfigured (either by on-line reconfiguration, as described in this manual, or when the system is shutdown, reconfigured, and rebooted). It is even possible for the path identifiers to change when no physical reconfiguration has been done, as a result of timing variations during the discovery process when the system boots, or when a bus is re-scanned.
The operating system provides several non-persistent names to represent these access paths to storage devices. One is the
/dev/sd name; another is the
major:minor number. A third is a symlink maintained in the
/dev/disk/by-path/ directory. This symlink maps from the path identifier to the current
/dev/sd name. For example, for a Fibre Channel device, the PCI info and
info may appear as follows:
pci-0000:02:0e.0-scsi-0:0:0:0 -> ../../sda
For iSCSI devices,
by-path/ names map from the target name and portal information to the
sd name.
It is generally not appropriate for applications to use these path-based names. This is because the storage device these paths reference may change, potentially causing incorrect data to be written to the device. Path-based names are also not appropriate for multipath devices, because the path-based names may be mistaken for separate storage devices, leading to uncoordinated access and unintended modifications of the data.
In addition, path-based names are system-specific. This can cause unintended data changes when the device is accessed by multiple systems, such as in a cluster.
For these reasons, several persistent, system-independent, methods for identifying devices have been developed. The following sections discuss these in detail.
The World Wide Identifier (WWID) can be used in reliably identifying devices. It is a persistent, system-independent ID that the SCSI Standard requires from all SCSI devices. The WWID identifier is guaranteed to be unique for every storage device, and independent of the path that is used to access the device.
This identifier can be obtained by issuing a SCSI Inquiry to retrieve the Device Identification Vital Product Data (page
0x83) or Unit Serial Number (page
0x80). The mappings from these WWIDs to the current
/dev/sd names can be seen in the symlinks maintained in the
/dev/disk/by-id/ directory.
For example, a device with a page
0x83 identifier would have:
scsi-3600508b400105e210000900000490000 -> ../../sda
Or, a device with a page
0x80 identifier would have:
scsi-SSEAGATE_ST373453LW_3HW1RHM6 -> ../../sda
Red Hat Enterprise Linux 5 automatically maintains the proper mapping from the WWID-based device name to a current
/dev/sd name on that system. Applications can use the
/dev/disk/by-id/ name to reference the data on the disk, even if the path to the device changes, and even when accessing the device from different systems.
If there are multiple paths from a system to a device, device-mapper-multipath uses the WWID to detect this. Device-mapper-multipath then presents a single "pseudo-device" in
/dev/mapper/wwid, such as
The command
multipath -l shows the mapping to the non-persistent identifiers:
/dev/sd name, and the
major:minor number.
3600508b400105df70000e00000ac0000 dm-2 vendor,product [size=20G][features=1 queue_if_no_path][hwhandler=0][rw] \_ round-robin 0 [prio=0][active] \_ 5:0:1:1 sdc 8:32 [active][undef] \_ 6:0:1:1 sdg 8:96 [active][undef] \_ round-robin 0 [prio=0][enabled] \_ 5:0:0:1 sdb 8:16 [active][undef] \_ 6:0:0:1 sdf 8:80 [active][undef]
Device-mapper-multipath automatically maintains the proper mapping of each WWID-based device name to its corresponding
/dev/sd name on the system. These names are persistent across path changes, and they are consistent when accessing the device from different systems.
When the
user_friendly_names feature (of device-mapper-multipath) is used, the WWID is mapped to a name of the form
/dev/mapper/mpath. By default, this mapping is maintained in the file
/var/lib/multipath/bindings. These
mpathn names are persistent as long as that file is maintained.
The multipath bindings file (by default,
/var/lib/multipath/bindings) must be available at boot time. If
/var is a separate filesystem from
/, then you must change the default location of the file. For more information, refer to http://kbase.redhat.com/faq/docs/DOC-17650.
If you use
user_friendly_names, then additional steps are required to obtain consistent names in a cluster. Refer to the Consistent Multipath Device Names section in the Using Device-Mapper Multipath book.
In addition to these persistent names provided by the system, you can also use
udev rules to implement persistent names of your own, mapped to the WWID of the storage. For more information about this, refer to http://kbase.redhat.com/faq/docs/DOC-7319.
If a storage device contains a filesystem, then that filesystem may provide one or both of the following:
- Universally Unique Identifier (UUID)
- Filesystem label
These identifiers are persistent, and based on metadata written on the device by certain applications. They may also be used to access the device using the symlinks maintained by the operating system in the
/dev/disk/by-label/ (e.g.
boot -> ../../sda1 ) and
/dev/disk/by-uuid/ (e.g.
f8bf09e3-4c16-4d91-bd5e-6f62da165c08 -> ../../sda1) directories.
md and LVM write metadata on the storage device, and read that data when they scan devices. In each case, the metadata contains a UUID, so that the device can be identified regardless of the path (or system) used to access it. As a result, the device names presented by these facilities are persistent, as long as the metadata remains unchanged.
Before removing access to the storage device itself, it is advisable to back up data from the device first. Afterwards, flush I/O and remove all operating system references to the device (as described below). If the device uses multipathing, then do this for the multipath "pseudo device" (Section 4.1, "WWID") and each of the identifiers that represent a path to the device. If you are only removing a path to a multipath device, and other paths will remain, then the procedure is simpler, as described in Section 7, "Adding a Storage Device or Path".
Removal of a storage device is not recommended when the system is under memory pressure, since the I/O flush will add to the load. To determine the level of memory pressure, run the command
vmstat 1 100; device removal is not recommended if:
- Free memory is less than 5% of the total memory in more than 10 samples per 100 (the command
freecan also be used to display the total memory).
- Swapping is active (non-zero
socolumns in the
The general procedure for removing all access to a device is as follows:
Procedure 1. Ensuring a Clean Device Removal
- Close all users of the device and backup device data as needed.
- Use
umountto unmount any file systems that mounted the device.
- Remove the device from any
mdand LVM volume using it. If the device is a member of an LVM Volume group, then it may be necessary to move data off the device using the
pvmovecommand, then use the
vgreducecommand to remove the physical volume, and (optionally)
pvremoveto remove the LVM metadata from the disk.
- If the device uses multipathing, run
multipath -land note all the paths to the device. Afterwards, remove the multipathed device using
multipath -f device.
- Run
blockdev –flushbufsto flush any outstanding I/O to all paths to the device. This is particularly important for raw devices, where there is no
vgreduceoperation to cause an I/O flush.
- Remove any reference to the device's path-based name, like
/dev/disk/by-pathor the
major:minornumber, in applications, scripts, or utilities on the system. This is important in ensuring that different devices added in the future will not be mistaken for the current device.
- Finally, remove each path to the device from the SCSI subsystem. To do so, use the command
echo 1 > /sys/block/where
may be
sde, for example.Another variation of this operation is
echo 1 > /sys/class/scsi_device/, where
is the HBA number,
is the channel on the HBA,
is the SCSI target ID, and
is the LUN.
NoteThe older form of these commands,
echo "scsi remove-single-device 0 0 0 0" > /proc/scsi/scsi, is deprecated.
You can determine the
, HBA number, HBA channel, SCSI target ID and LUN for a device from various commands, such as
multipath -l, and
ls -l /dev/disk/by-*.
After performing Procedure 1, "Ensuring a Clean Device Removal", a device can be physically removed safely from a running system. It is not necessary to stop I/O to other devices while doing so.
Other procedures, such as the physical removal of the device, followed by a rescan of the SCSI bus (as described in Section 9, "Scanning Storage Interconnects") to cause the operating system state to be updated to reflect the change, are not recommended. This will cause delays due to I/O timeouts, and devices may be removed unexpectedly. If it is necessary to perform a rescan of an interconnect, it must be done while I/O is paused, as described in Section 9, "Scanning Storage Interconnects".
If you are removing a path to a device that uses multipathing (without affecting other paths to the device), then the general procedure is as follows:
Procedure 2. Removing a Path to a Storage Device
- Remove any reference to the device's path-based name, like
/dev/disk/by-pathor the
major:minornumber, in applications, scripts, or utilities on the system. This is important in ensuring that different devices added in the future will not be mistaken for the current device.
- Take the path offline using
echo offline > /sys/block/sda/device/state.This will cause any subsequent IO sent to the device on this path to be failed immediately. Device-mapper-multipath will continue to use the remaining paths to the device.
- Remove the path from the SCSI subsystem. To do so, use the command
echo 1 > /sys/block/where
may be
sde, for example (as described in Procedure 1, "Ensuring a Clean Device Removal").
After performing Procedure 2, "Removing a Path to a Storage Device", the path can be safely removed from the running system. It is not necessary to stop I/O while this is done, as device-mapper-multipath will re-route I/O to remaining paths according to the configured path grouping and failover policies.
Other procedures, such as the physical removal of the cable, followed by a rescan of the SCSI bus to cause the operating system state to be updated to reflect the change, are not recommended. This will cause delays due to I/O timeouts, and devices may be removed unexpectedly. If it is necessary to perform a rescan of an interconnect, it must be done while I/O is paused, as described in Section 9, "Scanning Storage Interconnects".
When adding a device, be aware that the path-based device name (
/dev/sd name,
major:minor number, and
/dev/disk/by-path name, for example) the system assigns to the new device may have been previously in use by a device that has since been removed. As such, ensure that all old references to the path-based device name have been removed. Otherwise, the new device may be mistaken for the old device.
Procedure 3. Add a storage device or path
- The first step in adding a storage device or path is to physically enable access to the new storage device, or a new path to an existing device. This is done using vendor-specific commands at the Fibre Channel or iSCSI storage server. When doing so, note the LUN value for the new storage that will be presented to your host. If the storage server is Fibre Channel, also take note of the World Wide Node Name (WWNN) of the storage server, and determine whether there is a single WWNN for all ports on the storage server. If this is not the case, note the World Wide Port Name (WWPN) for each port that will be used to access the new LUN.
- Next, make the operating system aware of the new storage device, or path to an existing device. The recommended command to use is:
echo "
c t l" > /sys/class/scsi_host/host
h/scanIn the previous command,
is the HBA number,
is the channel on the HBA,
is the SCSI target ID, and
is the LUN.
NoteThe older form of this command,
echo "scsi add-single-device 0 0 0 0" > /proc/scsi/scsi, is deprecated.
For Fibre Channel storage servers that implement a single WWNN for all ports, you can determine the correct
- In some Fibre Channel hardware, a newly created LUN on the RAID array may not be visible to the operating system until a Loop Initialization Protocol (LIP) operation is performed. Refer to Section 9, "Scanning Storage Interconnects" for instructions on how to do this.
ImportantIt will be necessary to stop I/O while this operation is executed if an LIP is required.
- If a new LUN has been added on the RAID array but is still not being configured by the operating system, confirm the list of LUNs being exported by the array using the
sg_lunscommand, part of the sg3_utils package. This will issue the
SCSI REPORT LUNScommand to the RAID array and return a list of LUNs that are present.
values (i.e. HBA number, HBA channel, and SCSI target ID) by searching for the WWNN in
sysfs. For example, if the WWNN of the storage server is
0x5006016090203181, use:
# grep 5006016090203181 /sys/class/fc_transport/*/node_nameThis should display output similar to the following:
/sys/class/fc_transport/target5:0:2/node_name:0x5006016090203181 /sys/class/fc_transport/target5:0:3/node_name:0x5006016090203181 /sys/class/fc_transport/target6:0:2/node_name:0x5006016090203181 /sys/class/fc_transport/target6:0:3/node_name:0x5006016090203181This indicates there are four Fibre Channel routes to this target (two single-channel HBAs, each leading to two storage ports). Assuming a LUN value is
56, then the following command will configure the first path:
# echo "0 2 56" > /sys/class/scsi_host/host5/scanThis must be done for each path to the new device.For Fibre Channel storage servers that do not implement a single WWNN for all ports, you can determine the correct HBA number, HBA channel, and SCSI target ID by searching for each of the WWPNs in
sysfs.Another way to determine the HBA number, HBA channel, and SCSI target ID is to refer to another device that is already configured on the same path as the new device. This can be done with various commands, such as
multipath -l, and
ls -l /dev/disk/by-*. This information, plus the LUN number of the new device, can be used as shown above to probe and configure that path to the new device.
- After adding all the SCSI paths to the device, execute the
multipathcommand, and check to see that the device has been properly configured. At this point, the device can be added to
md, LVM,
mkfs, or
mount, for example.
If the steps above are followed, then a device can safely be added to a running system. It is not necessary to stop I/O to other devices while this is done. Other procedures involving a rescan (or a reset) of the SCSI bus, which cause the operating system to update its state to reflect the current device connectivity, are not recommended while storage I/O is in progress.
The fcoe-utilspackage, which provides a Fibre-Channel Over Ethernet interface, is enabled as a Technology Preview in Red Hat Enterprise Linux 5.10. However, this Technology Preview excludes the dcdb package, which provides the data center bridging demon.
For further information about Technology Previews, refer to https://access.redhat.com/support/offerings/techpreview/.
There are several commands available that allow you to reset and/or scan one or more interconnects, potentially adding and removing multiple devices in one operation. This type of scan can be disruptive, as it can cause delays while I/O operations timeout, and remove devices unexpectedly. As such, Red Hat recommends that this type of scan be used only when necessary. In addition, the following restrictions must be observed when scanning storage interconnects:
- All I/O on the effected interconnects must be paused and flushed before executing the procedure, and the results of the scan checked before I/O is resumed.
- As with removing a device, interconnect scanning is not recommended when the system is under memory pressure. To determine the level of memory pressure, run the command
vmstat 1 100; interconnect scanning is not recommended if free memory is less than 5% of the total memory in more than 10 samples per 100. It is also not recommended if swapping is active (non-zero
socolumns in the
vmstatoutput). The command
freecan also display the total memory.
The following commands can be used to scan storage interconnects.
echo "1" > /sys/class/fc_host/host/issue_lip
- This operation performs a Loop Initialization Protocol (LIP) and then scans the interconnect and causes the SCSI layer to be updated to reflect the devices currently on the bus. A LIP is, essentially, a bus reset, and will cause device addition and removal. This procedure is necessary to configure a new SCSI target on a Fibre Channel interconnect.Bear in mind that
issue_lipis an asynchronous operation. The command may complete before the entire scan has completed. You must monitor
/var/log/messagesto determine when it is done.The
qla2xxxdrivers support
issue_lip. For more information about the API capabilities supported by each driver in Red Hat Enterprise Linux, refer to Table 1, "Fibre-Channel API Capabilities".
- This script is included in Red Hat Enterprise Linux 5.4 and all future updates. By default, this script scans all the SCSI buses on the system, updating the SCSI layer to reflect new devices on the bus. The script provides additional options to allow device removal and the issuing of LIPs. For more information about this script (including known issues), refer to Section 16, "Adding/Removing a Logical Unit Through rescan-scsi-bus.sh".
echo "- - -" > /sys/class/scsi_host/host
- This is the same command described in Section 7, "Adding a Storage Device or Path" to add a storage device or path. In this case, however, the channel number, SCSI target ID, and LUN values are replaced by wildcards. Any combination of identifiers and wildcards is allowed, allowing you to make the command as specific or broad as needed. This procedure will add LUNs, but not remove them.
rmmod driver-nameor
modprobe driver-name
- These commands completely re-initialize the state of all interconnects controlled by the driver. Although this is extreme, it may be appropriate in some situations. This may be used, for example, to re-start the driver with a different module parameter value.
WarningVarious problems have been seen when unloading and reloading drivers. Although some of these problems have been addressed, the problems will be present in previous releases. Additionally, current releases may have unresolved problems. Driver loading and unloading should not be done in a production environment.
The default iSCSI configuration file is
/etc/iscsi/iscsid.conf. This file contains iSCSI settings used by
iscsid and
During target discovery, the
iscsiadm tool uses the settings in
/etc/iscsi/iscsid.conf to create two types of records:
- Node records in
- When logging into a target,
iscsiadmuses the settings in this file.
- Discovery records in
- When performing discovery to the same destination,
iscsiadmuses the settings in this file.
Before using different settings for discovery, delete the current discovery records (i.e.
/var/lib/iscsi/) first. To do this, use the following command:
iscsiadm -m discovery -t [1]
discovery_type -p
port -o delete
can be either
isns, or
fw. [2]
There are two ways to reconfigure discovery record settings:
- Edit the
/etc/iscsi/iscsid.conffile directly prior to performing a discovery. Discovery settings use the prefix
discovery; to view them, run:
iscsiadm -m discovery -t
- Alternatively,
iscsiadmcan also be used to directly change discovery record settings, as in:
iscsiadm -m discovery -t
port-o update -n
setting-v %
valueRefer to
man iscsiadmfor more information on available
s and valid
s for each.
After configuring discovery settings, any subsequent attempts to discover new targets will use the new settings. Refer to Section 12, "Scanning iSCSI Interconnects" for details on how to scan for new iSCSI targets.
For more information on configuring iSCSI target discovery, refer to the
man pages of
iscsiadm and
iscsid. The
/etc/iscsi/iscsid.conf file also contains examples on proper configuration syntax.
This chapter describes how to set up iSCSI interfaces in order to bind a session to a NIC port when using software iSCSI. It also describes how to set up interfaces for use with network devices that support offloading; namely, devices from Chelsio, Broadcom and ServerEngines.
The network subsystem can be configured to determine the path/NIC that iSCSI interfaces should use for binding. For example, if portals and NICs are set up on different subnets, then it is not necessary to manually configure iSCSI interfaces for binding.
Before attempting to configure an iSCSI interface for binding, run the following command first:
ping -I eth[1]
ping fails, then you will not be able to bind a session to a NIC. If this is the case, check the network settings first.
Red Hat Enterprise Linux 5.5 supports iSCSI offload and interface binding for the following iSCSI initiator implementations:
- Software iSCSI — like the
ib_isermodules, this stack allocates an iSCSI host instance (i.e.
scsi_host) per session, with a single connection per session. As a result,
/proc/scsiwill report a
scsi_hostfor each connection/session you are logged into.
- Offload iSCSI — like the Chelsio
cxgb3i, Broadcom
bnx2iand ServerEngines
be2iscsimodules, this stack allocates a
scsi_hostfor each PCI device. As such, each port on a host bus adapter will show up as a different PCI device, with a different
scsi_hostper HBA port.
To manage both types of initiator implementations,
iscsiadm uses the
iface structure. With this structure, an
iface configuration must be entered in
/var/lib/iscsi/ifaces for each HBA port, software iSCSI, or network device (
eth) used to bind sessions.
To view available
iface configurations, run
iscsiadm -m iface. This will display
iface information in the following format:
Refer to the following table for an explanation of each value/setting.
Table 2. iface Settings
iface configuration name.
|Name of driver
|MAC address
|IP address to use for this port
Name used for the
vlan or alias binding of a software iSCSI session. For iSCSI offloads,
net_iface_name will be
<empty> because this value is not persistent across reboots.
This setting is used to override a default name for the initiator, which is defined in
The following is a sample output of the
iscsiadm -m iface command:
iface0 qla4xxx,00:c0:dd:08:63:e8,188.8.131.52,default,iqn.2005-06.com.redhat:madmax iface1 qla4xxx,00:c0:dd:08:63:ea,22.214.171.124,default,iqn.2005-06.com.redhat:madmax
For software iSCSI, each
iface configuration must have a unique name (with less than 65 characters). The
iface_name for network devices that support offloading appears in the format
For example, the sample output of
iscsiadm -m iface on a system using a Chelsio network card might appear as:
default tcp,<empty>,<empty>,<empty>,<empty> iser iser,<empty>,<empty>,<empty>,<empty> cxgb3i.00:07:43:05:97:07 cxgb3i,00:07:43:05:97:07,<empty>,<empty>,<empty>
It is also possible to display the settings of a specific
iface configuration in a more friendly way. To do so, use the option
-I . This will display the settings in the following format:
Using the previous example, the
iface settings of the same Chelsio video card (i.e.
iscsiadm -m iface -I cxgb3i.00:07:43:05:97:07) would appear as:
# BEGIN RECORD 2.0-871 iface.iscsi_ifacename = cxgb3i.00:07:43:05:97:07 iface.net_ifacename = <empty> iface.ipaddress = <empty> iface.hwaddress = 00:07:43:05:97:07 iface.transport_name = cxgb3i iface.initiatorname = <empty> # END RECORD
As mentioned earlier, an
iface configuration is required for each network object that will be used to bind a session.
To create an
iface configuration for software iSCSI, run the following command:
iscsiadm -m iface -I
iface_name --op=new
This will create a new empty
iface configuration with a specified
. If an existing
iface configuration already has the same
, then it will be overwritten with a new, empty one.
To configure a specific setting of an
iface configuration, use the following command:
iscsiadm -m iface -I
iface_name --op=update -n iface.
setting -v
For example, to set the MAC address (
hardware_address) of
iface0 to
00:0F:1F:92:6B:BF, run:
iscsiadm -m iface -I iface0 - -op=update -n iface.hwaddress -v 00:0F:1F:92:6B:BF
Do not use
default or
iser as
iface names. Both strings are special values used by
iscsiadm for backward compatibility. Any manually-created
iface configurations named
default or
iser will disable backwards compatibility.
By default,
iscsiadm will create an
iface configuration for each Chelsio, Broadcom, and ServerEngines port. To view available
iface configurations, use the same command for doing so in software iSCSI, i.e.
iscsiadm -m iface.
Before using the
iface of a network card for iSCSI offload, first set the IP address (
[1]) that the device should use. For ServerEngines devices that use the
be2iscsi driver (i.e. ServerEngines iSCSI HBAs), the IP address is configured in the ServerEngines BIOS setup screen.
For Chelsio and Broadcom devices, the procedure for configuring the IP address is the same as for any other
iface setting. So to configure the IP address of the
iface, use:
iscsiadm -m iface -I
iface_name -o update -n iface.ipaddress -v
For example, to set the
iface IP address of a Chelsio card (with
iface name
cxgb3i.00:07:43:05:97:07) to
18.104.22.168, use:
iscsiadm -m iface -I cxgb3i.00:07:43:05:97:07 -o update -n iface.ipaddress -v 22.214.171.124
iscsiadm is used to scan for interconnects, it will first check the
iface.transport settings of each
iface configuration in
/var/lib/iscsi/ifaces. The
iscsiadm utility will then bind discovered portals to any
iface whose
iface.transport is
This behavior was implemented for compatibility reasons. To override this, use the
-I to specify which portal to bind to an
iface, as in:
iscsiadm -m discovery -t st -p [1]
target_IP:port -I
iface_name -P 1
By default, the
iscsiadm utility will not automatically bind any portals to
iface configurations that use offloading. This is because such
iface configurations will not have
iface.transport set to
tcp. As such, the
iface configurations of Chelsio, Broadcom, and ServerEngines ports need to be manually bound to discovered portals.
It is also possible to prevent a portal from binding to any existing
iface. To do so, use
default as the
, as in:
iscsiadm -m discovery -t st -p
IP:port -I default -P 1
To remove the binding between a target and
iface, use:
iscsiadm -m node -targetname [3]
proper_target_name -I iface0 --op=delete
To delete all bindings for a specific
iface, use:
iscsiadm -m node -I
iface_name --op=delete
To delete bindings for a specific portal (e.g. for EqualLogic targets), use:
iscsiadm -m node -p
IP:port -I
iface_name --op=delete
If there are no
iface configurations defined in
/var/lib/iscsi/iface and the
-I option is not used,
iscsiadm will allow the network subsystem to decide which device a specific portal should use.
For iSCSI, if the targets send an iSCSI async event indicating new storage is added, then the scan is done automatically. Cisco MDS™ and EMC Celerra™ support this feature.
However, if the targets do not send an iSCSI async event, you need to manually scan them using the
iscsiadm utility. Before doing so, however, you need to first retrieve the proper
--targetname and the
--portal values. If your device model supports only a single logical unit and portal per target, use
iscsiadm to issue a
sendtargets command to the host, as in:
iscsiadm -m discovery -t sendtargets -p [1]
The output will appear in the following format:
For example, on a target with a
iqn.1992-08.com.netapp:sn.33615311 and a
10.15.85.19:3260, the output may appear as:
10.15.84.19:3260,2 iqn.1992-08.com.netapp:sn.33615311 10.15.85.19:3260,3 iqn.1992-08.com.netapp:sn.33615311
In this example, the target has two portals, each using
s of
10.15.84.19:3260 and
To see which
iface configuration will be used for each session, add the
-P 1 option. This option will print also session information in tree format, as in:
target_portal_group_tagIface Name:
For example, with
iscsiadm -m discovery -t sendtargets -p 10.15.85.19:3260 -P 1, the output may appear as:
Target: iqn.1992-08.com.netapp:sn.33615311 Portal: 10.15.84.19:3260,2 Iface Name: iface2 Portal: 10.15.85.19:3260,3 Iface Name: iface2
This means that the target
iqn.1992-08.com.netapp:sn.33615311 will use
iface2 as its
iface configuration.
With some device models (e.g. from EMC and Netapp), however, a single target may have multiple logical units and/or portals. In this case, issue a
sendtargets command to the host first to find new portals on the target. Then, rescan the existing sessions using:
iscsiadm -m session --rescan
You can also rescan a specific session by specifying the session's
value, as in:
iscsiadm -m session -r [4]
SID --rescan
If your device supports multiple targets, you will need to issue a
sendtargets command to the hosts to find new portals for each target. Then, rescan existing sessions to discover new logical units on existing sessions (i.e. using the
--rescan option).
sendtargets command used to retrieve
--targetname and
--portal values overwrites the contents of the
/var/lib/iscsi/nodes database. This database will then be repopulated using the settings in
/etc/iscsi/iscsid.conf. However, this will not occur if a session is currently logged in and in use.
To safely add new targets/portals or delete old ones, use the
-o new or
-o delete options, respectively. For example, to add new targets/portals without overwriting
/var/lib/iscsi/nodes, use the following command:
iscsiadm -m discovery -t st -p
target_IP -o new
To delete
/var/lib/iscsi/nodes entries that the target did not display during discovery, use:
iscsiadm -m discovery -t st -p
target_IP -o delete
You can also perform both tasks simultaneously, as in:
iscsiadm -m discovery -t st -p
target_IP -o delete -o new
sendtargets command will yield the following output:
For example, given a device with a single target, logical unit, and portal, with
equallogic-iscsi1 as your
, the output should appear similar to the following:
10.16.41.155:3260,0 iqn.2001-05.com.equallogic:6-8a0900-ac3fe0101-63aff113e344a4a2-dl585-03-1
Note that
are identical to the values of the same name in Section 3.1, "iSCSI API".
At this point, you now have the proper
--targetname and
--portal values needed to manually scan for iSCSI devices. To do so, run the following command:
iscsiadm --mode node --targetname
proper_target_name --portal
Using our previous example (where
equallogic-iscsi1), the full command would be:
iscsiadm --mode node --targetname \
iqn.2001-05.com.equallogic:6-8a0900-ac3fe0101-63aff113e344a4a2-dl585-03-1 \
--portal 10.16.41.155:3260,0 [5]
It is possible to append a
--login option to a discovery command. This combines the two steps of discovering target portals and logging in to them. For example,
iscsiadm --mode node --targetname [5]
proper_target_name --portal
ip:port,target_portal_group_tag\ --login
As mentioned in Section 3, "iSCSI", the iSCSI service must be running in order to discover or log into targets. To start the iSCSI service, run:
service iscsi start
When this command is executed, the iSCSI
init scripts will automatically log into targets where the
node.startup setting is configured as
automatic. This is the default value of
node.startup for all targets.
To prevent automatic login to a target, set
node.startup to
manual. To do this, run the following command:
iscsiadm -m node --targetname
proper_target_name -p
target_IP:port -o update -n node.startup -v manual
Deleting the entire record will also prevent automatic login. To do this, run:
iscsiadm -m node --targetname
proper_target_name -p
target_IP:port -o delete
To automatically mount a file system from an iSCSI device on the network, add a partition entry for the mount in
/etc/fstab with the
_netdev option. For example, to automatically mount the iSCSI device
sdb to
/mount/iscsi during startup, add the following line to
/dev/sdb /mnt/iscsi ext3 _netdev 0 0
To manually log in to an iSCSI target, use the following command:
iscsiadm -m node --targetname
proper_target_name -p
target_IP:port -l
refer to the full name and IP address/port combination of a target. For more information, refer to Section 3.1, "iSCSI API" and Section 12, "Scanning iSCSI Interconnects".
This chapter will cover resizing online logical units, including resizing fibre channel logical units, resizing an iSCSI logical units, and updating the size of a multipath device, as well as changing the read/write state of onlin logical units.
In most cases, fully resizing an online logical unit involves two things: resizing the logical unit itself and reflecting the size change in the corresponding multipath device (if multipathing is enabled on the system).
To resize the online logical unit, start by modifying the logical unit size through the array management interface of your storage device. This procedure differs with each array; as such, consult your storage array vendor documentation for more information on this.
In order to resize an online file system, the file system must not reside on a partitioned device.
After modifying the online logical unit size, re-scan the logical unit to ensure that the system detects the updated size. To do this for Fibre Channel logical units, use the following command:
echo 1 > /sys/block/sd
To re-scan fibre channel logical units on a system that uses multipathing, execute the aforementioned command for each sd device (i.e.
sd2, and so on) that represents a path for the multipathed logical unit. To determine which devices are paths for a multipath logical unit, use
multipath -ll; then, find the entry that matches the logical unit being resized. It is advisable that you refer to the WWID of each entry to make it easier to find which one matches the logical unit being resized.
After modifying the online logical unit size, re-scan the logical unit to ensure that the system detects the updated size. To do this for iSCSI devices, use the following command:
iscsiadm -m node --targetname [1]
target_name -R
with the name of the target where the device is located.
You can also re-scan iSCSI logical units using the following command:
iscsiadm -m node -R -I
with the corresponding interface name of the resized logical unit (for example,
iface0). This command performs two operations:
- It scans for new devices in the same way that the command
echo "- - -" > /sys/class/scsi_host/does (refer to Section 12, "Scanning iSCSI Interconnects").
- It re-scans for new/modified logical units the same way that the command
echo 1 > /sys/block/sdX/device/rescandoes. Note that this command is the same one used for re-scanning fibre-channel logical units.
If multipathing is enabled on your system, you will also need to reflect the change in logical unit size to the logical unit's corresponding multipath device (after resizing the logical unit). For Red Hat Enterprise Linux 5.3 (or later), you can do this through
multipathd. To do so, first ensure that
multipathd is running using
service multipathd status. Once you've verified that
multipathd is operational, run the following command:
multipathd -k"resize map
variable is the corresponding multipath entry of your device in
/dev/mapper. Depending on how multipathing is set up on your system,
can be either of two formats:
mpath, where
is the corresponding entry of your device (for example,
- a WWID; for example,
To determine which multipath entry corresponds to your resized logical unit, run
multipath -ll. This displays a list of all existing multipath entries in the system, along with the major and minor numbers of their corresponding devices.
Do not use
multipathd -k"resize map if there are any commands queued to
. That is, do not use this command when the
no_path_retry parameter (in
/etc/multipath.conf) is set to
"queue", and there are no active paths to the device.
If your system is using Red Hat Enterprise Linux 5.0-5.2, you will need to perform the following procedure to instruct the
multipathd daemon to recognize (and adjust to) the changes you made to the resized logical unit:
Procedure 4. Resizing the Corresponding Multipath Device (Required for Red Hat Enterprise Linux 5.0 - 5.2)
- Dump the device mapper table for the multipathed device using:
dmsetup table
- Save the dumped device mapper table as
. This table will be re-loaded and edited later.
- Examine the device mapper table. Note that the first two numbers in each line correspond to the start and end sectors of the disk, respectively.
- Suspend the device mapper target:
dmsetup suspend
- Open the device mapper table you saved earlier (i.e.
). Change the second number (i.e. the disk end sector) to reflect the new number of 512 byte sectors in the disk. For example, if the new disk size is 2GB, change the second number to 4194304.
- Reload the modified device mapper table:
dmsetup reload
- Resume the device mapper target:
dmsetup resume
For more information about multipathing, refer to the Using Device-Mapper Multipath guide (in http://www.redhat.com/docs/manuals/enterprise/).
Certain storage devices provide the user with the ability to change the state of the device from Read/Write (R/W) to Read-Only (RO), and from RO to R/W. This is typically done through a management interface on the storage device. The operating system will not automatically update its view of the state of the device when a change is made. Follow the procedures described in this chapter to make the operating system aware of the change.
Run the following command, replacing XYZ with the desired device designator, to determine the operating system's current view of the R/W state of a device:
# blockdev --getro /dev/sd
The following command is also available for Red Hat Enterprise Linux 6:
# cat /sys/block/sd
XYZ/ro 1 = read-only 0 = read-write
When using multipath, refer to the ro or rw field in the second line of output from the
multipath -ll command. For example:
36001438005deb4710000500000640000 dm-8 GZ,GZ500 [size=20G][features=0][hwhandler=0][ro] \_ round-robin 0 [prio=200][active] \_ 6:0:4:1 sdax 67:16 [active][ready] \_ 6:0:5:1 sday 67:32 [active][ready] \_ round-robin 0 [prio=40][enabled] \_ 6:0:6:1 sdaz 67:48 [active][ready] \_ 6:0:7:1 sdba 67:64 [active][ready]
To change the R/W state, use the following procedure:
Procedure 5. Change the R/W state
- To move the device from RO to R/W, see step 2.To move the device from R/W to RO, ensure no further writes will be issued. Do this by stopping the application, or through the use of an appropriate, application-specific action.Ensure that all outstanding write I/Os are complete with the following command:
# blockdev -flushbufs /dev/
devicewith the desired designator; for a device mapper multipath, this is the entry for your device in
dev/mapper. For example,
- Use the management interface of the storage device to change the state of the logical unit from R/W to RO, or from RO to R/W. The procedure for this differs with each array. Consult applicable storage array vendor documentation for more information.
- Perform a re-scan of the device to update the operating system's view of the R/W state of the device. If using a device mapper multipath, perform this re-scan for each path to the device before issuing the command telling multipath to reload its device maps.This process is explained in further detail in Section 15.1, "Rescanning logical units".
After modifying the online logical unit Read/Write state, as described in Section 15, "Changing the Read/Write State of an Online Logical Unit", re-scan the logical unit to ensure the system detects the updated state with the following command:
# echo 1 > /sys/block/sd
To re-scan logical units on a system that uses multipathing, execute the above command for each sd device that represents a path for the multipathed logical unit. For example, run the command on sd1, sd2 and all other sd devices. To determine which devices are paths for a multipath unit, use
multipath -11, then find the entry that matches the logical unit to be changed.
Example 1. Use of the
multipath -11 command
For example, the
multipath -11 above shows the path for the LUN with WWID 36001438005deb4710000500000640000. In this case, enter:
# echo 1 > /sys/block/sd
# echo 1 > /sys/block/sd
# echo 1 > /sys/block/sd
# echo 1 > /sys/block/sd
If multipathing is enabled, after rescanning the logical unit, the change in its state will need to be reflected in the logical unit's corresponding multipath drive. Do this by reloading the multipath device maps with the following command:
# multipath -r
multipath -11 command can then be used to confirm the change.
Further information can be found in the Red Hat Knowledgebase. To access this, navigate to https://www.redhat.com/wapps/sso/login.html?redirect=https://access.redhat.com/knowledge/ and log in. Then access the article at https://access.redhat.com/kb/docs/DOC-32850.
sg3_utils package provides the
rescan-scsi-bus.sh script, which can automatically update the logical unit configuration of the host as needed (after a device has been added to the system). The
rescan-scsi-bus.sh script can also perform an
issue_lip on supported devices. For more information about how to use this script, refer to
rescan-scsi-bus.sh --help.
To install the
sg3_utils package, run
yum install sg3_utils.
When using the
rescan-scsi-bus.sh script, take note of the following known issues:
- A race condition requires that
rescan-scsi-bus.shbe run twice if logical units are mapped for the first time. During the first scan,
rescan-scsi-bus.shonly adds
LUN0; all other logical units are added in the second scan.
- A bug in the
rescan-scsi-bus.shscript incorrectly executes the functionality for recognizing a change in logical unit size when the
--removeoption is used.
- The
rescan-scsi-bus.shscript does not recognize ISCSI logical unit removals.
This section describes how to modify the link loss behavior of devices that use either fibre channel or iSCSI protocols.
If a driver implements the Transport
dev_loss_tmo callback, access attempts to a device through a link will be blocked when a transport problem is detected. To verify if a device is blocked, run the following command:
cat /sys/block/
This command will return
blocked if the device is blocked. If the device is operating normally, this command will return
Procedure 6. Determining The State of a Remote Port
- To determine the state of a remote port, run the following command:
cat /sys/class/fc_remote_port/rport-
- This command will return
Blockedwhen the remote port (along with devices accessed through it) are blocked. If the remote port is operating normally, the command will return
- If the problem is not resolved within
dev_loss_tmoseconds, the rport and devices will be unblocked and all IO running on that device (along with any new IO sent to that device) will be failed.
Procedure 7. Changing
- To change the
echoin the desired value to the file. For example, to set
dev_loss_tmoto 30 seconds, run:
echo 30 > /sys/class/fc_remote_port/rport-
For more information about
dev_loss_tmo, refer to Section 2.1, "Fibre Channel API".
When a device is blocked, the fibre channel class will leave the device as is; i.e.
/dev/sd will remain
/dev/sd. This is because the
dev_loss_tmo expired. If the link problem is fixed at a later time, operations will continue using the same SCSI device and device node name.
If you prefer that devices are removed at the SCSI layer when links are marked bad (i.e. expired after
dev_loss_tmo seconds), you can use the
scsi_transport_fc module parameter
remove_on_dev_loss. When a device is removed at the SCSI layer while
remove_on_dev_loss is in effect, the device will be added back once all transport problems are corrected.
The use of
remove_on_dev_loss is not recommended, as removing a device at the SCSI layer does not automatically unmount any file systems from that device. When file systems from a removed device are left mounted, the device may not be properly removed from multipath or RAID devices.
Further problems may arise from this if the upper layers are not hotplug-aware. This is because the upper layers may still be holding references to the state of the device before it was originally removed. This can cause unexpected behavior when the device is added again.
dm-multipath is implemented, it is advisable to set iSCSI timers to immediately defer commands to the multipath layer. To configure this, nest the following line under
device { in
features "1 queue_if_no_path"
This ensures that I/O errors are retried and queued if all paths are failed in the
dm-multipath layer.
You may need to adjust iSCSI timers further to better monitor your SAN for problems. Available iSCSI timers you can configure are NOP-Out Interval/Timeouts and
replacement_timeout, which are discussed in the following sections.
To help monitor problems the SAN, the iSCSI layer sends a NOP-Out request to each target. If a NOP-Out request times out, the iSCSI layer responds by failing any running commands and instructing the SCSI layer to requeue those commands when possible.
dm-multipath is being used, the SCSI layer will fail those running commands and defer them to the multipath layer. The multipath layer then retries those commands on another path. If
dm-multipath is not being used, those commands are retried five times before failing altogether.
Intervals between NOP-Out requests are 10 seconds by default. To adjust this, open
/etc/iscsi/iscsid.conf and edit the following line:
node.conn[0].timeo.noop_out_interval =
[interval value]
Once set, the iSCSI layer will send a NOP-Out request to each target every
[interval value] seconds.
By default, NOP-Out requests time out in 10 seconds[6]. To adjust this, open
/etc/iscsi/iscsid.conf and edit the following line:
node.conn[0].timeo.noop_out_timeout =
[timeout value]
This sets the iSCSI layer to timeout a NOP-Out request after
[timeout value] seconds.
Note that this will not work for iSCSI targets already logged in or discovered once. In this case run
iscsiadm to update configuration values explicitly.
iscsiadm -m node -T
$target_ip:$port-o update -n \ node.session.timeo.replacement_timeout -v
If the SCSI Error Handler is running, running commands on a path will not be failed immediately when a NOP-Out request times out on that path. Instead, those commands will be failed after
replacement_timeout seconds. For more information about
replacement_timeout, refer to Section 17.2.2, "
To verify if the SCSI Error Handler is running, run:
iscsiadm -m session -P 3
replacement_timeout controls how long the iSCSI layer should wait for a timed-out path/session to reestablish itself before failing any commands on it. The default
replacement_timeout value is 120 seconds.
To adjust
replacement_timeout, open
/etc/iscsi/iscsid.conf and edit the following line:
node.session.timeo.replacement_timeout =
1 queue_if_no_path option in
/etc/multipath.conf sets iSCSI timers to immediately defer commands to the multipath layer (refer to Section 17.2, "iSCSI Settings With
dm-multipath"). This setting prevents I/O errors from propagating to the application; because of this, you can set
replacement_timeout to 15-20 seconds.
By configuring a lower
replacement_timeout, I/O is quickly sent to a new path and executed (in the event of a NOP-Out timeout) while the iSCSI layer attempts to re-establish the failed path/session. If all paths time out, then the multipath and device mapper layer will internally queue I/O based on the settings in
/etc/multipath.conf instead of
Note that this will not work for iSCSI targets already logged in or discovered once. In this case run
iscsiadm to update configuration values explicitly.
iscsiadm -m node -T
$target_ip:$port-o update -n \ node.session.timeo.replacement_timeout -v
Whether your considerations are failover speed or security, the recommended value for
replacement_timeout will depend on other factors. These factors include the network, target, and system workload. As such, it is recommended that you thoroughly test any new configurations to
replacements_timeout before applying it to a mission-critical system.
The iSCSI tools do not use the
iscsid.conf settings for portals that have already been discovered and logged into. To modify the settings of a portal that has already been discovered and set up, run:
iscsiadm -m node -T
$port-o update -n \ node.session.timeo.replacement_timeout -v
The above command will modify the portal's record so the next time the iSCSI tools log in, that value will be used.
The value on a running session cannot be modified. For the value to be used, either restart the iSCSI service, or run the
iscsiadm logout command on that session, then log back in.
To set the value to be the new default for all newly discovered portals, set the value in
iscsid.conf. Next time the
iscsiadm discovery command is run and portals are found, the new value will be used.
When accessing the root partition directly through a iSCSI disk, the iSCSI timers should be set so that iSCSI layer has several chances to try to reestablish a path/session. In addition, commands should not be quickly re-queued to the SCSI layer. This is the opposite of what should be done when
dm-multipath is implemented.
To start with, NOP-Outs should be disabled. You can do this by setting both NOP-Out interval and timeout to zero. To set this, open
/etc/iscsi/iscsid.conf and edit as follows:
node.conn[0].timeo.noop_out_interval = 0 node.conn[0].timeo.noop_out_timeout = 0
In line with this,
replacement_timeout should be set to a high number. This will instruct the system to wait a long time for a path/session to reestablish itself. To adjust
replacement_timeout, open
/etc/iscsi/iscsid.conf and edit the following line:
node.session.timeo.replacement_timeout =
After configuring
/etc/iscsi/iscsid.conf, you must perform a re-discovery of the affected storage. This will allow the system to load and use any new values in
/etc/iscsi/iscsid.conf. For more information on how to discover iSCSI devices, refer to Section 12, "Scanning iSCSI Interconnects".
You can also configure timeouts for a specific session and make them non-persistent (instead of using
/etc/iscsi/iscsid.conf). To do so, run the following command (replace the variables accordingly):
iscsiadm -m node -T
target_name -p
port -o update -n node.session.timeo.replacement_timeout -v $
The configuration described here is recommended for iSCSI sessions involving root partition access. For iSCSI sessions involving access to other types of storage (namely, in systems that use
dm-multipath), refer to Section 17.2, "iSCSI Settings With
The Linux SCSI layer sets a timer on each command. When this timer expires, the SCSI layer will quiesce the host bus adapter (HBA) and wait for all outstanding commands to either time out or complete. Afterwards, the SCSI layer will activate the driver's error handler.
When the error handler is triggered, it attempts the following operations in order (until one successfully executes):
- Abort the command.
- Reset the device.
- Reset the bus.
- Reset the host.
If all of these operations fail, the device will be set to the
offline state. When this occurs, all IO to that device will be failed, until the problem is corrected and the user sets the device to
The process is different, however, if a device uses the fibre channel protocol and the
rport is blocked. In such cases, the drivers wait for several seconds for the
rport to become online again before activating the error handler. This prevents devices from becoming offline due to temporary transport problems.
To display the state of a device, use:
cat /sys/block/
To set a device to
running state, use:
echo running > /sys/block/
To control the command timer, you can write to
/sys/block/. To do so, run:
value /sys/block/
is the timeout value (in seconds) you want to implement.
Alternatively, you can also modify the timeout
udev rule. To do so, open
/etc/udev/rules.d/50-udev.rules. You should find the following lines:
ACTION=="add", SUBSYSTEM=="scsi" , SYSFS{type}=="0|7|14", \ RUN+="/bin/sh -c 'echo 60 > /sys$$DEVPATH/timeout'"
echo 60 refers to the timeout length, in seconds; in this case, timeout is set at 60 seconds. Replace this value with your desired timeout length.
Note that the default timeout for normal file system commands is 60 seconds when
udev is being used. If
udev is not in use, the default timeout is 30 seconds.
This section provides solution to common problems users experience during online storage reconfiguration.
- Logical unit removal status is not reflected on the host.
- When a logical unit is deleted on a configured filer, the change is not reflected on the host. In such cases,
lvmcommands will hang indefinitely when
dm-multipathis used, as the logical unit has now become stale.To work around this, perform the following procedure:
Procedure 8. Working Around Stale Logical Units
- Determine which
mpathlink entries in
/etc/lvm/cache/.cacheare specific to the stale logical unit. To do this, run the following command:
ls -l /dev/mpath | grep
- For example, if
is 3600d0230003414f30000203a7bc41a00, the following results may appear:
lrwxrwxrwx 1 root root 7 Aug 2 10:33 /3600d0230003414f30000203a7bc41a00 -> ../dm-4 lrwxrwxrwx 1 root root 7 Aug 2 10:33 /3600d0230003414f30000203a7bc41a00p1 -> ../dm-5This means that 3600d0230003414f30000203a7bc41a00 is mapped to two
- Next, open
/etc/lvm/cache/.cache. Delete all lines containing
and the
mpathlinks that
maps to.
stale-logical-unitUsing the same example in the previous step, the lines you need to delete are:
/dev/dm-4 /dev/dm-5 /dev/mapper/3600d0230003414f30000203a7bc41a00 /dev/mapper/3600d0230003414f30000203a7bc41a00p1 /dev/mpath/3600d0230003414f30000203a7bc41a00 /dev/mpath/3600d0230003414f30000203a7bc41a00p1
A. Revision History
|Revision History
|Revision 1-26
|Tue Apr 15 2014
|Revision 1-24
|Tue Oct 1 2013
|Revision 1-20
|Tue May 28 2013
|Revision 1-19
|Fri May 17 2013
|Revision 1-17
|Wed May 15 2013
|Revision 1-16
|Wed Jul 11 2012
|Revision 1-15
|Fri May 25 2012
|Revision 1-13
|Thu May 24 2012
|Revision 1-9
|Fri Sep 16 2011
- /dev/disk
- persistent naming, Persistent Naming
- adding paths to a storage device, Adding a Storage Device or Path
- API, fibre channel, Fibre Channel API
- API, iSCSI, iSCSI API
- blocked device, verifying
- fibre channel
- modifying link loss behavior, Fibre Channel
- changing dev_loss_tmo
- fibre channel
- modifying link loss behavior, Fibre Channel
- Changing the read/write state
- Online logical units, Changing the Read/Write State of an Online Logical Unit
- command timer (SCSI)
- Linux SCSI layer, Command Timer
- controlling SCSI command timer and device status
- Linux SCSI layer, Controlling the SCSI Command Timer and Device Status
- determining remote port states
- fibre channel
- modifying link loss behavior, Fibre Channel
- device status
- Linux SCSI layer, Device States
- devices, removing, Removing a Storage Device
- dev_loss_tmo
- fibre channel
- modifying link loss behavior, Fibre Channel
- fibre channel API, Fibre Channel API
- dev_loss_tmo, changing
- fibre channel
- modifying link loss behavior, Fibre Channel
- disabling NOP-Outs
- iSCSI configuration, iSCSI Root
- dm-multipath
- iSCSI configuration, iSCSI Settings With dm-multipath
- drivers (native), fibre channel, Native Fibre Channel Drivers and Capabilities
- entries, device mapper table, Updating the Size of Your Multipath Device
- fast_io_fail_tmo
- fibre channel API, Fibre Channel API
- feedback
- contact information for this manual, We Need Feedback!
- fibre channel API, Fibre Channel API
- fibre channel drivers (native), Native Fibre Channel Drivers and Capabilities
- help
- getting help, Do You Need Help?
- host
- fibre channel API, Fibre Channel API
- iSCSI API, iSCSI API
- iSCSI logical unit, resizing, Resizing an iSCSI Logical Unit
- iSCSI root
- iSCSI configuration, iSCSI Root
- issue_lip
- fibre channel API, Fibre Channel API
- modifying link loss behavior, Modifying Link Loss Behavior
- fibre channel, Fibre Channel
- native fibre channel drivers, Native Fibre Channel Drivers and Capabilities
- NOP-Out requests
- modifying link loss
- iSCSI configuration, NOP-Out Interval/Timeout
- NOP-Outs (disabling)
- iSCSI configuration, iSCSI Root
- offline status
- Linux SCSI layer, Controlling the SCSI Command Timer and Device Status
- Online logical units, Online Logical Units
- Changing the read/write state, Changing the Read/Write State of an Online Logical Unit
- path to storage devices, adding, Adding a Storage Device or Path
- path to storage devices, removing, Removing a Path to a Storage Device
- persistent naming, Persistent Naming
- port states (remote), determining
- fibre channel
- modifying link loss behavior, Fibre Channel
- queue_if_no_path
- iSCSI configuration, iSCSI Settings With dm-multipath
- modifying link loss
- iSCSI configuration, replacement_timeout
- remote port
- fibre channel API, Fibre Channel API
- remote port states, determining
- fibre channel
- modifying link loss behavior, Fibre Channel
- remove_on_dev_loss
- fibre channel
- modifying link loss behavior, Fibre Channel: remove_on_dev_loss
- removing devices, Removing a Storage Device
- removing paths to a storage device, Removing a Path to a Storage Device
- replacement_timeout
- modifying link loss
- iSCSI configuration, SCSI Error Handler, replacement_timeout
- replacement_timeoutM
- iSCSI configuration, iSCSI Root
- resized logical units, resizing, Resizing an Online Logical Unit
- resizing an iSCSI logical unit, Resizing an iSCSI Logical Unit
- resizing multipath device
- resizing online resized logical units, Updating the Size of Your Multipath Device
- resizing resized logical units, Resizing an Online Logical Unit
- running sessions, retrieving information about
- iSCSI API, iSCSI API
- running status
- Linux SCSI layer, Controlling the SCSI Command Timer and Device Status
- scanning storage interconnects, Scanning Storage Interconnects
- SCSI command timer
- Linux SCSI layer, Command Timer
- SCSI Error Handler
- modifying link loss
- iSCSI configuration, SCSI Error Handler
- specific session timeouts, configuring
- iSCSI configuration, Configuring Timeouts for a Specific Session
- storage interconnects, scanning, Scanning Storage Interconnects
- symbolic links in /dev/disk
- persistent naming, Persistent Naming
- timeouts for a specific session, configuring
- iSCSI configuration, Configuring Timeouts for a Specific Session
- transport
- fibre channel API, Fibre Channel API
- udev
- persistent naming, WWID
- udev rule (timeout)
- command timer (SCSI), Command Timer
- Universally Unique Identifier (UUID)
- persistent naming, UUID and Other Persistent Identifiers
- userspace API files
- fibre channel API, Fibre Channel API
- persistent naming, UUID and Other Persistent Identifiers
- verifying if a device is blocked
- fibre channel
- modifying link loss behavior, Fibre Channel
[1] The
variables refer to the IP address and port combination of a target/portal, respectively. For more information, refer to Section 3.1, "iSCSI API" and Section 12, "Scanning iSCSI Interconnects".
[2] For details on different types of discovery, refer to the DISCOVERY TYPES section of
man iscsiadm.
[3] Refer to Section 12, "Scanning iSCSI Interconnects" for information on
[4] For information on how to retrieve a session's SID value, refer to Section 3.1, "iSCSI API".
[5] This is a single command split into multiple lines, to accommodate printed and PDF versions of this document. All concatenated lines — preceded by the backslash (\) — should be treated as one command, sans backslashes.
[6] Prior to Red Hat Enterprise Linux 5.4, the default NOP-Out requests time out was 15 seconds.


text:
The Founder Institute is coming to Philly!
|Seed Philly, 1650 Arch Street, Suite 1906, Philadelphia, PA, 19103
Enrollment for this event is closed. Get updates on new events.
The Founder Institute is coming to Philly!
...and to introduce us to Philly, we're holding several events so that you can learn more about the program and meet some of the team. Join us for this informational event where you can meet the local Directors, ask questions, and learn how you can launch a startup with the Founder Institute's help.
Who Should Attend the Information Session?
- Anyone who has an idea for a startup or an early-stage company.
- Anyone that is interested in joining a new startup or looking for a co-founder.
- Anyone interested in learning about the Founder Institute program.
What is the Agenda?
- Welcome and Socializing
- Introduction to the Founder Institute
- Q&A about the Founder Institute
- Attendee Introductions
- Discussion
FI-Philly is being brought to you by entrepreneurs and mentors Herb Cohen, Bob Solomon, and Mike Krupit.
Guest speakers for the first event include:
Gabriel Weinberg, CEO & Founder, DuckDuckGo, Angel InvestorGabriel Weinberg is the CEO and founder of DuckDuckGo, a search engine. Previously he founded NamesDatabase, which was sold to Classmates.com in 2006. Weinberg was educated at MIT, with a B.S. in Physics and an M.S. in Technology and Policy. He is also an active angel investor and blogger.
Mike Levinson, CEO & Founder, WizeHive; Founding Partner, DreamIt VenturesMike Levinson is a Founding Partner at DreamIt Ventures and co-founder and CEO of WizeHive, an SaaS productivity tool growing 100% year over year; and an active angel investor with a portfolio of over a dozen technology companies. Before DreamIt, Mike co-founded PTS Learning Systems, a company focused on corporate technology education and electronic performance support tools. Under his leadership, the company grew into a highly profitable international organization with over 200 employees and revenues of $30 million until he sold it 1999.

subset: commoncrawl


text:
Tip: Put a + in front of words that must be included. To search for Monster Hunter and only receive results with both words, use +Monster +Hunter
I know they are a small piece of this costume but I just have to compliment you on those silver shoes *_*. Lovely!
United States


text:
6-Pocket Literature Display (Stand-Up or Wall-Mount)
Estimated shipping date: Monday, June 26 (Click for more details)
Order by 1pm ET tomorrow for shipping by Monday, June 26.
This side-by-side, three-tier clear literature display is excellent for tracts, pamphlets, trifolds and other items up to 4" x 9". Overall dimensions are 9 1/4" wide x 12 5/8" tall x 6 1/2" deep. Versatile design can stand on a desk, or easily be mounted on a wall. Center dividers can be removed to allow for materials up to 8.75" wide.


text:
Hello there! I'm Trevor Pott; a writer and sysadmin from Edmonton, Alberta, Canada. When I'm not lashing networks together I spend my time writing articles for various tech magazines or doing marketing consulting for technology startups. I am cofounder of eGeek Consulting Ltd.
If for whatever reason you are possessed by the strange and disturbing desire to learn even more about me (you may want to have that looked at, by the way) a Q&A published by Spiceworks is here.
For PR folks and marketing bodies interested in pitching me, I recommend the Countdown-2-VMworld Q&A with me which you can read here. It will give you a leg up against the torrent of press releases in my inbox every day.
I have been recognized as a vExpert for 2013, 2014, 2015, 2016 and 2017.
I have been recognized as a vExpert-NSX for 2016.
Who I write for:
Virtualization and Cloud Review
I write a column called "The Cranky Admin" for Virtualization Review, as well as assigned features, reviews, and deep-dives. My articles and be found here.
The Register
I am a freelance writer for The Register. My articles and be found here.
I write VMware focused "expert tips" and advice articles for SearchVmware. These articles can be found here.
WeBreakTech Along with my coworkers at eGeek (and with the contributions of geeks the world over) I have started my own tech blog with a focus on technology hardware, software and services reviews. My blogs and reviews can be found here.
Ethical considerations:
I am frequently placed under NDA or embargo by clients or vendors; these NDAs will be respected. Information under NDA will not be blogged about, tweeted about or otherwise discussed without the client's permission. The may require me to withhold newsworthy information. It is a necessary part of working as a contractor and as a tech journalist.
Under no circumstances will I knowingly allow any vendor or client – no matter the NDA, embargo, posh junket or fat consulting check to censor my speech beyond the time limitations on publishing information. My first duty as a writer and as a consultant is to the truth; without a reputation for calling things as I see them my word in either field has no value.
My Testlab
I write a lot of reviews; those reviews are run on my testlab. You can find out more about it many of the components that make up my test lab – and how they are all put together – here (part 1, part 2).
Here I list companies that have provided me or my company with long-term review hardware, junkets, or with whom we currently have a long term contract.
One-off items, such as being paid to provide a single whitepaper or blog are not listed. These are left out both because those items are fixed deliverables and because we do so many of them for so many clients that listing them all would become a full time job in and of itself. Having discussed it with numerous individuals, the consensus is that it is reasonable to assume that fixed deliverable one-off items are unlikely to elicit bias.
Anything that does not fall into the above category which I feel offers even the possibility of eliciting bias is documented below. Items such as limited time subscriptions to software or cloud services are removed after they have expired.
My company has provided content (in one form or another) for a significant chunk of the virtualization and storage industry. I have personally done interviews with, written articles on, attended conference meetings/parties with or otherwise been schmoozed, briefed, sucked up to, threatened, praised and publicly denounced by virtually player in this space from deep stealth mode companies to the various goliaths.
The corporate view of eGeek Consulting Ltd regarding the maintenance of objectivity (and my personal view as well) is that attempting never to report on a company I have worked with, or never to work with the competitor of a company I am currently engaged with is impracticable. I prefer to work with everyone, and in that manner be beholden to no one.
I have accepted junkets from the following companies:
VMware: Flight and accommodation to San Francisco to be focus grouped about vSphere 5.1 (2012)
Microsoft: Flight and accommodation to a Server and Tools reviewer workshop to preview Server 2012 R2 (2013)
Spiceworks: Flight and accommodation to Spiceworlds 2012, 2013, 2014
Simplivity: Flight and accommodation to SimpliVity Connect Boston 2016
Scale Computing: Flight and accommodation for an NDAed analyst briefing in 2016
The following companies have provided components for my test lab as part of a review process:
Supermicro: Various servers, SSE-X24 and SSE-X3348T switches, Microserver.
Scale Computing: one 3-node HC1000 cluster and a remote archive node.
Dell: Powerconnect 8132F switch.
Intel: various network cards.
VMware: NFR software licences.
RetroUI: NFR software licences.
Western Digital: Sentinel DX4000, Sentinel DS6100, Sentinel DX4200
Micron: Various SSDs and RAM
ioSafe: ioSafe 214
Tintri: T-850 (On 1 year loan for review purposes)
For more details on how any why this practice comes about, see here. The above list does not not include access to products or services that I may be offered as part of my status as a vExpert. Although that status is largely based upon my activities as a blogger the perks are offered to all vExperts across the board.
My company is currently on monthly strategic consulting and content creation contracts with:
1x Hyperconvergence startup (Yottabyte)
1x Next Gen storage startup (ioFABRIC)
1x Copy Data Managment startup (Catalogic)
My comapny is currently on sysadmin contracts for:
1x Canadian photographic lab
5x Canadian ISPs/WISPs
1x Canadian video rendering lab
1x Canadian mineral exploration company
A seemingly unlimited number of photography companies
Trevor Pott is a full-time nerd from Edmonton, Alberta, Canada. He is cofounder of eGeek Consulting Ltd. and splits his time between systems administration, consulting and technology writing. As a consultant he helps Silicon Valley start-ups better understand systems administrators and how to sell to them.
Contact Info
My work Twitter handle is @egeekconsulting.
My personal Twitter handle is @cakeis_not_alie.
My LinkedIn profile is viewable here.
If you would like to contact me via e-mail please end email to trevor DOT p AT Trevorpott DOT com.
Shameless plug
If you are looking for someone to develop technical marketing material or do content creation take a wander over to eGeek.ca. We also assist vendors with grokking the variegations in the IT market. This ranges from market analysis to helping refine feature focus, develop go-to-market strategies and narrowing market targeting for specific campaigns. The eGeek website links to a price menu with a comprehensive list of our offerings.


text:
Richard Staite, banking analyst at SG Securities, said: 'A&L would be a sensible deal for Abbey, out of a limited range of options. The City is not over-fond of A&L's management and would rate Abbey's more highly.' A&L, which last month announced 500 job cuts and downgraded its performance targets, has had a tough year. Managing director Peter Macnamara resigned in the autumn. The group is now run by ebullient chairman John Windeler.
It loses its five-year immunity from takeover in April. Other possible bidders for the company, still 50%-owned by private shareholders, include National Australia Bank, Lloyds TSB and Royal Bank of Scotland, whose chief executive, Fred Goodwin, says he is looking for 'mercy killings'.
Analysts reckon a bidder would have to pay up to £9 a share for control. Abbey refused to comment. A bid is not thought to be imminent as most of its executives are on holiday. A&L said: 'We will always look at options.'
- More about:
- Banking
- Financial Instruments
- Securities


text:
First Communion Cross
The top cross on the cake was inspired by a cake I have seen here on CC. I think it is very feminine and so pretty. There is about 200 mini flowers on this cake. The base is quilting technique that gives a great effect. This is a vanilla cake with buttercream covered with fondant. All details are fondant.
You May Also Be Interested In
No Comments Yet
Login To Leave A Comment


text:
Contact: David E. Marion
PARIS IN THE TWENTIES. This course is a study of the literature written in (or about) the great artistic center, Paris, during the flamboyant and creative years from the end of the Great War to the Crash (1918-1929). The primary focus is modern literature and its cultural background, but attention also is given to other modern arts such as painting and music, and to politics, society, and the way of life in post-war Paris. Readings include works by F. Scott Fitzgerald, Gertrude Stein, Ernest Hemingway, Malcolm Cowley, and others who lived and worked in Paris in the nineteen-twenties. Prerequisite: none. Offered: May Term.
AFRICAN-AMERICAN CULTURE. This course examines the many achievements of African-Americans in the arts, music, politics, diplomacy, and the military. Students should gain an appreciation of the essential role that African-Americans have played in shaping the history, politics, and culture of the United States. Offered: on sufficient demand.
UNITED STATES MILITARY AND AMERICAN SOCIETY: IDEALS, INSTITUTIONS, AND ISSUES. A seminar primarily for sophomores enrolled in the Military Leadership track of the James Madison Public Service Certificate Program, but open to any interested student, the course combines lecture/conference instruction with student oral and written reports based on research assignments on such topics as the constitutional ideals undergirding our national military establishment; the relationship between the military and key national institutions, law enforcement agencies, and the media; and historical and contemporary legal, social, political, and cultural issues that both support and complicate the military's place in American society. Prerequisite: none. Offered: spring semester.
SEMINAR IN ENVIRONMENTAL STUDIES. A topical capstone experience for students in the Environmental Studies Minor, designed to integrate the various courses taken by the students (or by other students who have completed an appropriate subset of the designated courses required in the Minor but not officially enrolled in the program) and to allow reflection on and engagement with significant issues that arise in the study of the environment. Students are expected to apply the concepts and materials of related courses to meta-themes discussed in the seminar. Topics may include issues in ecology, the economics of environmentalism, and bioethics, as well as other scientific, social science, and humanistic concerns. Prerequisite: at least four courses required for the Environmental Studies Minor. Offered: spring semester.
LEADERSHIP AND PUBLIC SERVICE IN CONSTITUTIONAL CONTEXT. Beginning with an examination of the major historical developments that have shaped the place and role of administrative-class officials in the United States, this course provides students with a general introduction to significant legal and political dimensions of public-sector employment. Consideration is given to the general subject of public-service ethics, including such topics as conflict of interest regulations, and to the complexities of intergovernmental and inter-branch relations. The first segment of the course focuses on historical, ethical, and political themes, while the second part is devoted to management-related matters and legal issues. Prerequisites: junior standing and consent of the instructor. Offered: spring semester.
INTERDISCIPLINARY STUDIES 377-380. (1 each)
377 (Constitutional History/Culture) reviews the political thought of leading founders such as Washington, Madison, and Jefferson with the goal of understanding the "cultural" as well as the "governmental" dimensions of the American constitutional order. Attention also is given to the "reformist" thinking of Lincoln, Wilson, and Franklin Roosevelt.
378 (Budgeting) examines theories and practices associated with governmental budgeting with special attention given to object classification, performance, program, and zero-base budgeting.
379 (Organizational Science) examines various management theories that have been developed and applied within public-sector organizations. Assignments cover the work of Frederick Taylor, Herbert Maslow, Herbert Simon, and the New Public Administration Movement, among others.
380 (Administrative Law) introduces students to some of the major concepts and principles in the field of administrative law (e.g., sovereign immunity, "privilege" and "delegations" doctrines). Assigned readings include case material from judicial and administrative agencies, as well as commentaries by practitioners and theorists. Students enrolled in these "lab" courses are expected to attend presentations/workshops by speakers both on and off campus. Prerequisite: enrollment in the James Madison Public Service Certificate Program. Offered: one each semester.
PUBLIC SERVICE INTERNSHIP RESEARCH PROJECT. The internship, required of students in the Public Service Program, is to be combined with a research project. The internship and research project are closely supervised by a faculty member. Internships are arranged to complement the course work in the Public Service Program. Credit is awarded only following a public defense of the completed research project. The defense follows the pattern established for honors papers. Prerequisite: Interdisciplinary Studies 375. Offered: fall semester.
LEADERSHIP AND ETHICS. An advanced seminar focused on learning and developing requisite skills and qualifications for successfully meeting senior leadership challenges in various fields of endeavor (i.e., politics and government, including the military; organized religion; non-profit agencies; academe; scientific research and development; the corporate world; the entertainment arena, etc.). Major emphasis on identifying and understanding varying leadership styles and using case studies (actual and posited) for working out and solving problems and issues of leadership. Prerequisite: desirable, but not required, that students have completed the Student Leadership Development Program ("Society of '91") and be serving currently in a student leadership position at the College.
INTERDISCIPLINARY STUDIES 450-453. (3 each)
SEMINAR IN INTER-AMERICAN RELATIONS. This is an interdisciplinary capstone course for the Latin American Studies minor which addresses current or historical hemispheric issues from a Latin American perspective. The main purpose of the course is to prepare a team to represent a specific Latin American country at the Washington Model Organization of American States although participation in the MOAS is not mandatory, nor guaranteed. Students using this course to fulfill the requirements for the Latin American Studies minor must take it during their junior or senior year, and may take it up to two times in fulfillment of the minor. If a student chooses not to participate in the MOAS, he will instead produce a twenty page research paper, or its equivalent, in which he demonstrates an interdisciplinary grasp of a particular problem, issue, or phenomenon approached from a Latin American perspective. He will select his topic in consultation with the faculty member who is teaching the capstone and who, in turn, helps guide the student's research. This course is open to all students; however, permission of the instructor is required for enrollment. Offered: spring semester.
AN OVERVIEW OF U.S. NATIONAL INTELLIGENCE. This course provides a basic overview of the nature and purpose of U.S. foreign intelligence institutions and activities in support of foreign policy and national security. Central themes include the critical need for sound and timely intelligence in the formulation and conduct of U.S. foreign policy; the historical evolution of U.S. intelligence from colonial times to the present; moral and legal constraints imposed upon intelligence in an open, democratic society; and guidelines for preparing for a professional career in intelligence, with emphasis on the value of a broadly based, liberal education. Extensive use is made of the case-study approach for illustrative purposes. Each student is required to prepare and present an intelligence analysis focusing on a selected area of potential threat to U.S. foreign-policy interests. Students are chosen on the basis of class rank and at the discretion of the instructor.


text:
/// David Bryant, Chief Creative Officer, Organic
August 27, 2013 | TMA13
David Bryant is CCO of Organic, part of the Omnicom network. No stranger to Omnicom – in his late 20's he was also a founding member of their digital agency Tribal DDB.
Previously he worked as a Creative Strategist for Google, where he did product visioning and strategy, and created work across many different teams and platforms.
Bryant has received more than 40 awards for digital and film work including Cannes and D&AD, and served on for juries for the same.
He plays around with technology in his spare time.
Leave a Reply
You must be logged in to post a comment.


text:
December 18, 2012
Calendars was put to rest a while back, but that didn't stop listeners from gaining a little curiosity through the Cadie visuals that featured Phlo Finister and a tease of "I'm That Nigga" towards the end. Well Robb Bank$ finally unleashed the full YOTS version of "I'm That Nigga", which is produced by Nuri and Young Savage. Year Of The Savage is coming sooner than we may think, and it very well seems that the #SavageLifeTakeover has officially been initiated.
Download: Click Here


text:
Deloitte Oracle Cloud - Information Delivery, Senior Consultant in Pittsburgh, Pennsylvania
Deloitte is one of the leading professional services organizations in the United States, specializing in audit, tax, consulting and financial advisory services with clients in more than 20 industries. We provide powerful business solutions to some of the world s most well-known and respected companies, including more than 75 percent of the Fortune 100.At Deloitte, you can have a rewarding career on every level. In addition to challenging and meaningful work, you ll have the chance to give back to your community, make a positive impact on the environment, participate in a range of diversity and inclusion initiatives, and find the support, coaching, and training it takes to advance your career. Our commitment to individual choice lets you customize aspects of your career path, your educational opportunities and your benefits. And our culture of innovation means your ideas on how to improve our business and your clients will be heard.Analytics Information ManagementDeloitte Consulting's Analytics Information Management (AIM) Service Area designs, develops, and implements systems and processes to capture, integrate and distribute information in an enterprise. Our specific service offerings within the AIM area include:Information DeliveryData Management & ArchitectureDigital Finance Transformation Advanced Analytics Enablement Essential Functions of a Senior Consultant:Senior Consultants work within an engagement team. Key responsibilities will include:Function as integrators between business needs and technology solutions, helping to create technology solutions to meet clients business needs.Identifying business requirements, requirements management, functional design, prototyping, process design (including scenario design, flow mapping), testing, training, defining support procedures and supporting implementations. Analytics Information Management Senior Consultants Candidates are required to have:3 years of relevant technology architecture consulting or industry experience in Consulting and the Oracle products.Bachelor s Degree or 4 years equivalent professional experience. Experience with Oracle Data Integration ideally around on-prem and cloud based data integration strategies, Big Data, Cloud and Business Intelligence products & applications. Experience managing cloud projects.Proficient in one or more Oracle products: Oracle Cloud Services (OCS), Oracle Business Intelligence Technologies and applications (BICS, OTBI, Oracle R, Oracle BI Appliances, Oracle Data Integrator (ODI) or Oracle GoldenGate.Experience with traditional Data Warehousing implementations and OBIEE, OBIA is a plus however must have experience with above referenced technologies and strategies for implementation and design.Provide support on data quality components during the implementation of the solution architecture.Provide technical recommendations for optimized data access and retention for the data warehouse.Provide oversight support to the design, development and QA teams.Define areas of improvement to optimize data flows.Identify strategy for data acquisition and archival.Willingness to travel to client locations (80%). Qualified candidates are also required to have at least one full lifecycle project experience in one or more of the following areas:Development of statements of work and/or client proposals.Identify business opportunities to increase usability and profitability of information architecture.Experience with program leadership, governance and change enablement.Develop and manage vendor relationships.Lead workshops for client education.Manage resources and budget on client projects.Ability to scope out the effort and cost for an enterprise reporting solution.Ability to define how an enterprise information system will align with the organization s business and strategic objectives.Ability to manage multiple teams on a data warehousing engagement. In addition, successful Senior Consultant will also have the following preferred skills:Strong oral and written communication skills, including presentation skills (MS Visio, MS PowerPoint).Strong problem solving and troubleshooting skills with the ability to exercise mature judgment.Eagerness to mentor junior staff.An advanced degree in the area of specialization is preferred.
About Deloitte
As used in this document, Deloitte means Deloitte LLP and its subsidiaries. Please see www.deloitte.com/us/about for a detailed description of the legal structure of Deloitte LLP and its subsidiaries. All qualified applicants will receive consideration for employment without regard to race, color, religion, sex, sexual orientation, gender identity, national origin, age, disability or protected veteran status, or any other legally protected basis, in accordance with applicable law.
Disclaimer: If you are not reviewing this job posting on our Careers site (careers.deloitte.com) or one of our approved job boards we cannot guarantee the validity of this posting. For a list of our current postings, please visit us at careers.deloitte.com.
Category: Management Consulting


text:
Need an IgG Test in Saint Albans, WV? Simply order online 24/7 and get a fast, affordable IgG Test at a lab near you (Find More Locations):
Why would I get an IgG Test?
An IgG Test measures IgG antibodies in the blood. People in Saint Albans, WV order an IgG Test for general screening or to guide therapy.
How much does an IgG Test cost?
Our IgG Test prices include the doctor's order that you need to get tested in Saint Albans, WV, all lab fees and taxes, and a pdf copy of your results. For current prices, please CLICK HERE.
We are pleased to offer an IgG Test in Saint Albans, WV.
IgG Test in other cities near Saint Albans, WV:Alum Creek | Bancroft | Charleston | Dunbar | Hometown | Hurricane | Nitro | Poca | Scott Depot | Sod | South Charleston | Sumerco | Teays | Tornado | Winfield