Re: [libvirt] Re: [Libvir] ISCSI howto, example, etc?
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