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.
_______________________________________________
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
