openstack team mailing list archive

[Vishvananda Ishaya <vishvananda@xxxxxxxxx>]

The idea is that the backend should specify the lun number in provider_location when the volume is created.  The logic of defaulting to 1 or 0 is to support legacy volumes that may not have set the lun in provider_location.  The code previously would just determine the lun programatically on the compute side based on the iscsi_helper flag.

If your backend is creating volumes at lun 0 then it needs to put lun 0 in the provider_location string that gets stored in the database.

provider location field:
<portal><id> <iqn> <lunid>
example:
172.16.40.244:3260,1 iqn.2010-10.org.openstack:volume-00000007 0

Vish

On Feb 21, 2012, at 5:39 PM, John Griffith wrote:

> 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
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp