[libvirt] Re: [Libvir] ISCSI howto, example, etc?

[Stefan de Konink]

On Wed, 14 May 2008, Chris Lalancette wrote:

> Ug.  Yeah, that will do it.  What kernel version are you running that your sysfs
> looks like that?

I already send a message to open-iscsi group. Fix is trivial and even more
simple. I'm running 2.6.21-xen (gentoo) with open-iscsi-2.0.869.2.

Fix:
    snprintf(sysfs_path, PATH_MAX,
             "/sys/class/iscsi_session/session%s/device/"
             "target%d:%d:%d/%d:%d:%d:%d",
             session, target, channel, id, target, channel, id, lun);


  (so remove /block)

           /* OK, not . or ..; let's see if it is a SCSI device */
        if (len > 8 &&
            block_dirent->d_name[0] == 'b' &&
            block_dirent->d_name[1] == 'l' &&
            block_dirent->d_name[2] == 'o' &&
            block_dirent->d_name[3] == 'c' &&
            block_dirent->d_name[4] == 'k' &&
            block_dirent->d_name[5] == ':' &&
            block_dirent->d_name[6] == 's' &&
            block_dirent->d_name[7] == 'd') {
            /* looks like a scsi device, smells like scsi device; it must be
               a scsi device */
            dev = (char *) calloc(sizeof(char), len - 5);
            strncpy(dev, &(block_dirent->d_name[6]), (len - 6));

I guess that can be come a strncmp. And for sake of memory management an
if (dev != NULL) would be good too.

> It seems we have been shoved into a corner; we can't rely on the output of the
> iscsiadm tools, since we have already seen those change between versions.  And
> apparently we can't rely on sysfs paths to stay stable either.  Either we need
> some iscsiadm command with a known, stable output that we can call, or we need
> some sort of iSCSI API that we can call to get this information.  Either way, I
> think we need help from the iSCSI people, because the current position seem to
> be untenable.

I would love to see something like a iSCSI API. The parsing looks really
cute, but as you say it is so unreliable.


Next to this:

 /* the 0'th LUN isn't a real LUN, it's just a control LUN; skip it */

I think this is also a very strange idea of LUNs.


Stefan