Hi, Both for the initrd (see bug 209110) and for anaconda, it would be very convenient if iscsadm would print out the device (as in for example /dev/sdc) for the just attached disk(s). I no this is not something trivial to implement, but it would be very good to have. Currently it is very hard for for example anaconda to make a mapping between targetnames and devices, even though we need such a mapping in some cases (which we currently hack around). An added advantage of this, is that if iscsiadm would wait for the disk to be attached to by the scsi subsystem, then doing error checking for the entire iscsi chain would become much easier and then we can show proper errors when a user tries to attach to an iscsi disk from anaconda.
Oops accidentally choose iscsi instead of iscsi-initiator-utils as component, fixing.
(In reply to comment #0) > Hi, > > Both for the initrd (see bug 209110) and for anaconda, it would be very > convenient if iscsadm would print out the device (as in for example /dev/sdc) > for the just attached disk(s). I no this is not something trivial to implement, > but it would be very good to have. > > Currently it is very hard for for example anaconda to make a mapping between > targetnames and devices, even though we need such a mapping in some cases > (which we currently hack around). If you do iscsiadm -m session -P 3 then it prints out all the iscsi sessions info (what target and port we are connected to) and then prints out the disks accessed throught that session. If you do iscsiadm -m session -i %N -P 3 Where N is the session number then it prints out the iscsi session it prints out the session info for just that session. > > An added advantage of this, is that if iscsiadm would wait for the disk to be > attached to by the scsi subsystem, then doing error checking for the entire > iscsi chain would become much easier and then we can show proper errors when a > user tries to attach to an iscsi disk from anaconda. It does this already if I understand you right. When you do iscsiadm -m node .... -l iscsiadm does not return until we have logged into the target and the scsi level scan (the scan that finds scsi disks and sets them up and adds them) has completed. It actually only waits until the kernel level stuff is done. So the kernel scsi layer has done the device addition in the kernel and fired a hotplug event to userspace, then iscsiadm would return. We do not wait for udev to create the /dev/ nodes, so that may be where we are having a problem.
(In reply to comment #2) > Where N is the session number then it prints out the iscsi session it prints > out the session info for just that session. > Oh yeah, the session number N is the number you see after the transport name: # iscsiadm -m session tcp [2] 10.15.84.19:3260,2 iqn.1992-08.com.netapp:sn.33615311 In this case tcp is the transport name and 2 is the session number. This is the same number you see when you do: #iscsiadm -m session -P 1 Target: iqn.1992-08.com.netapp:sn.33615311 Current Portal: 10.15.85.19:3260,3 Persistent Portal: 10.15.85.19:3260,3 Iface Transport: tcp Iface IPaddress: 10.11.14.37 Iface HWaddress: default Iface Netdev: default SID: 7 iSCSI Connection State: LOGGED IN Internal iscsid Session State: NO CHANGE Here SID is the session number.
(In reply to comment #2) > (In reply to comment #0) > > Hi, > > > > Both for the initrd (see bug 209110) and for anaconda, it would be very > > convenient if iscsadm would print out the device (as in for example /dev/sdc) > > for the just attached disk(s). I no this is not something trivial to implement, > > but it would be very good to have. > > > > Currently it is very hard for for example anaconda to make a mapping between > > targetnames and devices, even though we need such a mapping in some cases > > (which we currently hack around). > > If you do > > iscsiadm -m session -P 3 > > then it prints out all the iscsi sessions info (what target and port we are > connected to) and then prints out the disks accessed through that session. > True, I know that, but that is a whole lot of text to parse for just getting sdX, so another option to get just that , or to specify what to print exactly would be welcome, but time may better be send in an other way, see below. <snip> > > > > An added advantage of this, is that if iscsiadm would wait for the disk to be > > attached to by the scsi subsystem, then doing error checking for the entire > > iscsi chain would become much easier and then we can show proper errors when a > > user tries to attach to an iscsi disk from anaconda. > > It does this already if I understand you right. When you do > > iscsiadm -m node .... -l > > iscsiadm does not return until we have logged into the target and the scsi > level scan (the scan that finds scsi disks and sets them up and adds them) has > completed. It actually only waits until the kernel level stuff is done. So the > kernel scsi layer has done the device addition in the kernel and fired a > hotplug event to userspace, then iscsiadm would return. We do not wait for udev > to create the /dev/ nodes, so that may be where we are having a problem. Ah, well that could potentially be fixed with a call to udevsettle (from anaconda not from iscsiadm). What my biggest "gripe" is, is that currently to things properly (which we currently do not, we have non existing error handling) we should do the following in anaconda (bash syntax): iscsiadm -m node .... -l udevsettle for dev in /sys/block/sd?/device; do iscsiadm -m session -r `readlink -f $dev` | grep node.name done To build a table of /dev/sdx <-> node-name mappings, which is a very convenient table to have. As the kernel (judging from dmesg) already knows the X in sdX which udev will assing to the "disk" (as the kernel tells udev the X) and as iscsiadm ... -l waits for the kernel to get this far, it would be nice if it could tell us straight away. --- However I think it is best not to spend time on this, as we (the anaconda team) have plans to do things differently wrt iscsi anyways. The plan is to split iscsi-initiator-utils into a lib and cmdline utils (which will work unchanged) using that lib. Then do python bindings for that lib and call the lib directly as that will give us much greater control over what is happening. I'll send you a mail with some more details on this.
(In reply to comment #4) > > True, I know that, but that is a whole lot of text to parse for just getting > sdX, so another option to get just that , or to specify what to print exactly > would be welcome, but time may better be send in an other way, see below. Yeah, that would be nice. I want to extend the current print_info argument. Instead of having it print different amounts of info, I want it to take a map for what you want, so you can just pass it some flag or flags that would indicate that just the devices should be printed or just the iscsi info or portal info or a mix of that info. This should be really simple. I have not done it because I was thinking about how to handle the backwards compat for the current amount of info way we do it.