freebsd stable - Oct 2017 - iSCSI: LUN modification error: LUN XXX is not managed by the block backend and LUN device confusion

Hi,


I got one more problem while dealing iSCSI targets in the production 
(yeah, I'm boring and stubborn). The environment is as in previous 
questions (a production site, hundreds of VMs and hundreds of disks). 
I've encountered this issue before, but this time i decided to ask 
whether it's possible that the reason is my inadequate actions.

We have two types of disks in production, one is called 
"userdata[number]" and another is called
"games[something+number]". The
iSCSI targets are named appropriately, plus userdata disks have the 
scsiname[number] option. Number simply indicates the VM it should be 
attached to. But sometimes some weird confusion happens, and I have two 
sorts of things, let me show them using one LUN as example (in reality 
right now I have 6 LUNs like this).

So from now we are considering the 310 as a VM tag, and two disks, 
userdata310 and games disk.

So imagine a piece of ctl.conf like this:

===Cut==
#
# worker310
#

target iqn.2016-04.net.playkey.iscsi:userdata-worker310 {
     initiator-portal 10.0.3.142/32
     portal-group playkey
     auth-type none

     lun 0 {
         option scsiname userdata310
         path /dev/zvol/data/userdata/worker310
     }
}

#
# worker310
#

target iqn.2016-04.net.playkey.iscsi:gamestop-worker310 {
     initiator-portal 10.0.3.142/32
     portal-group playkey
     auth-type none

     lun 0 {
         path /dev/zvol/data/reference-ver13_1233-worker310
     }
}

===Cut==
When the issue happens, I got the following line in the log:

Oct  4 12:00:55 san1 ctld[777]: LUN modification error: LUN 547 is not 
managed by the block backend
Oct  4 12:00:55 san1 ctld[777]: failed to modify lun 
"iqn.2016-04.net.playkey.iscsi:userdata-worker310,lun,0", CTL lun 547


In the "ctladm devlist -v" I see this about the LUN 547:

547 block           10737418240  512 MYSERIAL 738     MYDEVID 738
       lun_type=0
       num_threads=14
       file=/dev/zvol/data/reference-ver13_1233-worker228
ctld_name=iqn.2016-04.net.playkey.iscsi:gamestop-worker228,lun,0
       scsiname=userdata310


So, notice, that the userdata disk for VM310 has the devices for 
completely different VM (according to their names). Weird ! One may 
think that this is simply the misconfiguration and the games disk for 
worker228 VM simply has the erroneous scsiname option tag. But no, it 
hasn't:


#
# worker228
#

target iqn.2016-04.net.playkey.iscsi:gamestop-worker228 {
         initiator-portal  [...obfuscated...]/32
         portal-group playkey
         auth-type none

         lun 0 {
                 path /dev/zvol/data/reference-ver13_1233-worker228
         }
}


The workaround to this is simply to comment the troublesome LUNs/targets 
in the ctl.conf, reload, uncomment and reload again.

Am I doing something wrong ?


Thanks.

Eugene.