openstack team mailing list archive
Mailing list archive
Re: Problem in nova/volume/driver.py
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>
172.16.40.244:3260,1 iqn.2010-10.org.openstack:volume-00000007 0
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
> results = location.split(" ")
> properties['target_portal'] = results.split(",")
> properties['target_iqn'] = results
> properties['target_lun'] = int(results)
> except (IndexError, ValueError):
> if FLAGS.iscsi_helper == 'tgtadm':
> properties['target_lun'] = 1
> 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". :)
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp