Consistent naming with iscsi + udev

If you need to export the same iscsi discs to different machines, you may want to name it consistently between various hosts.
When you setup iSCSI drives, Linux names them in the usual and unreliable /dev/sdX way (to get started with iSCSI use Michelangelo’s post )

Standard SCSI disks have a serial identifier: you can get it querying the /sys/block filesystem:

 #udevadm info --path=/sys/block/sdb --query=all | grep ID_SERIAL=

or checking them via their name

 #udevadm info --name=/dev/mapper/oraqdisk1 --query=all | grep DM_UUID=

And use it to identify the disk with an udev rule:

#cat > /etc/udev/rules.d/99-disk.rule <<EOF
KERNEL=="sd*", ENV{ID_SERIAL}=="the_disc_unique_id", NAME="disk0", OWNER="storage", GROUP="storage", MODE="0660"

To make sure the iscsi discs you export via tgtd have an unique serial id, you have to set it in /etc/tgt/targets.conf

    <backing-store /dev/mapper/VolGroup-lv_storage_0>
            scsi_id babel_testplant_s0
    <backing-store /dev/mapper/VolGroup-lv_storage_1>
        scsi_id babel_testplant_s1
    vendor_id iSCSI ACME Inc.

At this point you just have to create the following:

#cat > /etc/udev/rules.d/99-iscsi.rule <<EOF
KERNEL=="sd*", ENV{ID_SERIAL}=="babel_testplant_s0", NAME="iscsi0", OWNER="storage", GROUP="storage", MODE="0660"
KERNEL=="sd*", ENV{ID_SERIAL}=="babel_testplant_s1", NAME="iscsi1", OWNER="storage", GROUP="storage", MODE="0660"

And reload udev

#udevadm trigger

You can even do bulk-naming using globbing (aka “*” ) and environment variables (aka %E).

# Discover multipath devices named "oraq*" and create the corrisponding device in /dev/oraqdisk1
#    for DM_NAME check /etc/multipath.conf
SUBSYSTEM=="block", ENV{DM_NAME}=="oraq*", NAME="%E{DM_NAME}", OWNER="grid", GROUP="oinstall", MODE="0600"

RHEV: extending a storage domain

Rhev – Red Hat Enterprise Virtualization 3.0 – stores data on special areas named Storage Domains (aka SD). An iscsi SD has lun attached – which is usually a Logical Volume (aka LV).

With current releases, you can’t grow a SD modifying the underlying LVs. This is probably due to the complex structure of the Storage Pool Manager which coordinates storage access from various hypervisors.

Let’s grow our “my_iscsi”. If we’re lucky we can do:
1- edit it in the rhev-manager interface;
2- add another LUN/Target to it.

In case the target lun exists but the rhev-manager can’t discover it, we may need to rediscover it trying to create a new storage domain. So:
a- try to create a new iscsi storage domain (don’t save it!);
b- discover for the missing target/lun so that rhev-manager is now aware of it;
c- close the create menu WITHOUT saving.

Now let’s re-select the “my_iscsi” and edit and we should see the new target! Once added to the SD click on “save” and we’re done.