iSCSI shared disks with custom device name on clients

adamitj

4/14/24, 5:52 PM

I'm using RHEL 7.9 (Maipo) and need to setup for all iSCSI clients the same device name, like /dev/sdb or /dev/thiscustomname.

I could do that by sharing the source disk using multipath, but for Db2 pureScale it cannot be a a symlink. This is how it is showing in the clients A and B:

Client A:

/dev/sdb                  mpath_me
└─/dev/mapper/db2data
/dev/sdc                  mpath_me
└─/dev/mapper/db2tieb

Client B (has 2 more disks than Client A):

/dev/sdd                  mpath_me
└─/dev/mapper/db2data
/dev/sde                  mpath_me
└─/dev/mapper/db2tieb

For Db2 purScale, when I issue an instance creation with the command:

/opt/ibm/db2/V115fp8ps/instance/db2icrt \
    -m  n1.local -mnet  n1  \
    -cf c1.local -cfnet c1  \
    -instance_shared_dev  /dev/mapper/db2data          \
    -tbdev                /dev/mapper/db2tieb          \
    -u  db2fenc1   db2inst1

The error is

DBI20013E  The database product installer detected that the given device path
"/dev/mapper/db2data" is a symbolic link on the host "c1.local".

Db2 pureScale instance creation complains about symlinks, so I cannot use any other entries in /dev/disk, because they're all symlinks and throws the same error:

/dev/disk/by-id
/dev/disk/by-label
/dev/disk/by-partlabel
/dev/disk/by-partuuid
/dev/disk/by-path
/dev/disk/by-uuid

That's the reason I need to use a device name (not a mapper name/symlink).

Is it possible that all clients have the same device name for these iSCSI remote disks, and, sure, ones that I can set myself like /dev/sfa or something way distant from the disks that kernel set for local disks (sda, sdb, sdc, etc.) ?

1 + 0

linux

storage

redhat

iscsi

kernel

Score:1

Server

Peter Zhabin

4/14/24, 6:20 PM

The names you're trying to have fixed are not supposed to persist in any modern Linux environment. Instead of trying to fix them, you should consider using any of /dev/disk/by-label, /dev/disk/by-uuid, /dev/disk/by-id or /dev/disk/by-path, depending on what kind of SAN you're using to back this storage.

+ 3

adamitj

4/14/24, 6:34 PM

I appreciate your comments, but you didn't pay attention to what I said: all entries under by-id, by-label, by-partlabel, by-partuuid, by-path and by-uuid are symlinks to the original devices (/dev/sda, /dev/sdb and so on). Db2 pureScale do not allow to create a instance because it reads them as symlinks and abort the installation. The error it throws is: "DBI20013E The database product installer detected that the given device path "/dev/mapper/db2data" is a symbolic link on the host "c1.local"." - The same occurs for any entry under /dev/disk/* .

adamitj

4/14/24, 6:41 PM

Based on your answer I updated my question to be more clear on the purpose. Thank you!

Peter Zhabin

4/14/24, 8:25 PM

Ok, I got your point, IBM still has its own way of doing things :). Based on that, the simplest solution would be to get real device name upon startup (I assume you're wrapping all this in systemd service or a script of some kind anyway) with something like `realdev=\`readlink -f /dev/mapper/db2data\`` and then reference `$realdev` in your instance launch command instead of device name.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: iSCSI shared disks with custom device name on clients

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.