[Openstack] Problem in nova/volume/driver.py

John Griffith john.griffith at solidfire.com
Wed Feb 22 01:39:50 UTC 2012


Hey Folks,

I was trying to work on bug #917245 today and had troubles connecting
my iSCSI devices.  After a bit of poking around I found the culprit in
nova/volume/driver.py


        results = location.split(" ")
        properties['target_portal'] = results[0].split(",")[0]
        properties['target_iqn'] = results[1]
        try:
            properties['target_lun'] = int(results[2])
        except (IndexError, ValueError):
            if FLAGS.iscsi_helper == 'tgtadm':
                properties['target_lun'] = 1
            else:
                properties['target_lun'] = 0

Unfortunately this doesn't work out very well.  First, I don't know
how to derive the lun number from the discovery (perhaps devices with
multi lun support and multiple luns reported from "report luns"
populate something here that I'm not familiar with, or maybe newer
version of iscsiadm give us some additional info), but the other
problem is how do we pick the correct default value to revert to?  In
the case of my particular device everything is Lun 0, and only Lun 0.
Looking at a wireshark trace you can see that report luns responds
with one lun and it's id is '0'.

So what happens in my case is when libvirt later goes through and
tries to attach the volume to an instance, it fails because the entry
it checks in /dev/disk/by_id has a mismatch in lun numbers.  I'm
planning to file a bug on this and assign it to myself, but I wanted
some input first.  I'm thinking that maybe there's a way to call
report luns or something and actually get the definitive value that
should be used here?  Or maybe there's another iscsiadm command that
will give us the info we need?

I'm wondering if anybody knows the logic here and perhaps would like
to educate me on the special case that I am not familiar with?  I also
figure I should make sure this wasn't changed by somebody to handle
their case where there device only support "Lun 1".  :)

Thanks,
John




More information about the Openstack mailing list