1

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.) ?

Improve this question

2 Answers 2

Reset to default
1

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.

Improve this answer
4
  • 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/* . Commented Apr 14, 2023 at 18:34
  • Based on your answer I updated my question to be more clear on the purpose. Thank you! Commented Apr 14, 2023 at 18:41
  • 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. Commented Apr 14, 2023 at 20:25
  • To be honest the answer of the question of this post is this. No doubt. But the problem I described really doesn't exists. For the ones seeking knowledge on Db2 pureScale, please read my own answer to this question. Commented Jan 30, 2024 at 22:08
0

Seems that I was looking into the wrong documentation and the wrong virtualization options. IBM Db2 pureScale feature uses WWN number (shown in lsblk -a -o WWN command). So it really doesn't matter if iSCSI disks are getting the same device name/number as in /dev/sda or /dev/sdb.

Another error was on the VMWare Workstation Pro 16/17 virtualization, which by default don't allow disks to have consistent UUID thus giving the same WWN number all over the VMs. To fix that, shutdown the VM and add this line in the main VM file (the one with .vmx extension):

disk.enableuuid = "TRUE"

Save the file and then restart the VM.

As I created all disks from scratch for each VM, that solved my problem. If you have cloned your VMs and disks, you'll need to find VMWare support to change disk UUID.

So the original problem of this question... is not really a problem.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.