0

We've been running a CentOS 7 server successfully for a couple months with two iSCSI targets, all set up using targetcli. These are mounted from a Windows 7 box using the MS iSCSI Initiator. Worked great. About a month ago, I added another target, to be mounted from a second machine. It seems I may have forgotten that I need to run saveconfig. Last week, we started to evaluate TigerStore, a metadata server. This is installed on a third Windows 7 machine. I set up a 4th target on the CentOS box for testing purposes with TigerStore (which also uses the Windows initiator to mount the target that it then serves up). Again, forgot that I need to saveconfig.

We have been using all four targets without issues. I was using it on Friday evening, in fact. However, when I came in this morning, the targets on the first machine, which have been mounted for months, were showing up with just a drive letter, and when clicked on, gave me a permissions error. I checked Windows machine #2, same thing with its one mounted iSCSI target. The TigerStore server was still connected to its target and working fine.

Rebooted all three Windows machines, same issue with permissions. Now is where I really screwed up: rebooted the CentOS server, and two of the target configurations are showing up with no LUNs (these are the two for which I didn't run saveconfig). Because... The location of the devices has changed. One pair was /dev/sdb1 and /dev/sdb2, and the other was /dev/sdc1 and /dev/sdc2, before the reboot. Now these are different, with /dev/sdc being my system drive, what was previously /dev/sdb is now /dev/sda, and /dev/sdc is now /dev/sdb. Thus, all the mappings are a mess.

So I guess I have a two-part question here:

1) Can I create new LUNs in targetcli to point to the new block device locations, in order to get the mappings to work correctly --WITHOUT-- altering the user data on the targets?

2) Can I force the system to use the same /dev/sd* location assignments at boot every time?

Ok, three part question:

3) If I can't do #2, what should I be doing differently to ensure that this doesn't happen again. For reference, here's the output of a targetcli ls:

o- / ..................................................................... [...]
  o- backstores .......................................................... [...]
  | o- block .............................................. [Storage Objects: 2]
  | | o- block1 ..................... [/dev/sdb1 (0 bytes) write-thru activated]
  | | | o- alua ............................................... [ALUA Groups: 1]
  | | |   o- default_tg_pt_gp ................... [ALUA state: Active/optimized]
  | | o- block3 ..................... [/dev/sdb2 (0 bytes) write-thru activated]
  | |   o- alua ............................................... [ALUA Groups: 1]
  | |     o- default_tg_pt_gp ................... [ALUA state: Active/optimized]
  | o- fileio ............................................. [Storage Objects: 0]
  | o- pscsi .............................................. [Storage Objects: 0]
  | o- ramdisk ............................................ [Storage Objects: 0]
  o- iscsi ........................................................ [Targets: 4]
  | o- iqn.2018-03.com.grd.t3 ............................ [TPGs: 1]
  | | o- tpg1 .............................................. [gen-acls, no-auth]
  | |   o- acls ...................................................... [ACLs: 0]
  | |   o- luns ...................................................... [LUNs: 1]
  | |   | o- lun0 ................ [block/block3 (/dev/sdb2) (default_tg_pt_gp)]
  | |   o- portals ................................................ [Portals: 1]
  | |     o- 10.0.0.1:3260 ................................................ [OK]
  | o- iqn.2018-03.com.grd:t1 ............................ [TPGs: 1]
  | | o- tpg1 .............................................. [gen-acls, no-auth]
  | |   o- acls ...................................................... [ACLs: 0]
  | |   o- luns ...................................................... [LUNs: 1]
  | |   | o- lun0 ................ [block/block1 (/dev/sdb1) (default_tg_pt_gp)]
  | |   o- portals ................................................ [Portals: 1]
  | |     o- 10.0.0.1:3260 ................................................ [OK]
  | o- iqn.2018-03.com.grd:t2 ............................ [TPGs: 1]
  | | o- tpg1 .............................................. [gen-acls, no-auth]
  | |   o- acls ...................................................... [ACLs: 0]
  | |   o- luns ...................................................... [LUNs: 0]
  | |   o- portals ................................................ [Portals: 1]
  | |     o- 10.0.0.1:3260 ................................................ [OK]
  | o- iqn.2018-04.com.grd:t3 ............................ [TPGs: 1]
  |   o- tpg1 .............................................. [gen-acls, no-auth]
  |     o- acls ...................................................... [ACLs: 0]
  |     o- luns ...................................................... [LUNs: 0]
  |     o- portals ................................................ [Portals: 1]
  |       o- 10.0.0.1:3260 ................................................ [OK]
  o- loopback ..................................................... [Targets: 0]
  o- srpt ......................................................... [Targets: 0]

Thanks!

2
  • Ok, I have answered the first two questions: I ended up deleting the blocks and LUNs and redoing them so they match the new /dev/sd* locations for the four targets. That's all working now. The third question remains - how the hell do I prevent this from happening again?
    – Perry
    Apr 30, 2018 at 19:36
  • And on the second question, I'm using blkid to get the partuuid value for each partition, and I'm mounting from /dev/disk/by-partuuid now
    – Perry
    May 8, 2018 at 19:15

1 Answer 1

0

The solution to this was to delete the backstore blocks and luns (leaving the targets in place). I then rebuilt the blocks in targetcli to point to the correct /dev/sd* locations.

Going forward, we're migrating all of these over using /dev/disk/by-partuuid to map the backstores to block devices, which should solve the persistence problem.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .