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