Interesting.  I didn't think discovery was necessary if you had the rest of the data already.  Is there a way to work around this without using discovery? The fallback seems fine, but I was trying to deprecate discovery.  I assume this is passing in devstack because the volume host is the same host as the compute host so the record exists.

On Jan 26, 2012, at 10:01 AM, Adam Gandelman wrote:

> Public bug reported:
> 
> I'm not sure if this is a general bug or specific to the tgt iscsi
> helper (will compare with ietd soon)
> 
> Attaching a volume to an instance results in the following errors in
> nova-compute.log on a libvirt compute node:
> http://paste.ubuntu.com/817916/
> 
> Manually walking thru the initiator commands on the compute node ends in
> the same results, mainly:
> 
> # iscsiadm -m node -T iqn.2010-10.org.openstack:volume-00000001 -p 192.168.20.4:3260
> iscsiadm: no records found!
> 
> It's not until I send a discovery to the target can I list any records,
> which (I assume) is the first step toward a successful volume attachment
> in nova.
> 
> root@test-03:~# iscsiadm -m discovery -t sendtargets -p 192.168.20.4:3260
> 192.168.20.4:3260,1 iqn.2010-10.org.openstack:volume-00000001
> root@test-03:~# iscsiadm -m node -T iqn.2010-10.org.openstack:volume-00000001 -p 192.168.20.4:3260
> # BEGIN RECORD 2.0-871
> node.name = iqn.2010-10.org.openstack:volume-00000001
> node.tpgt = 1
> node.startup = manual
> iface.hwaddress = <empty>
> iface.ipaddress = <empty>
> iface.iscsi_ifacename = default
> iface.net_ifacename = <empty>
> iface.transport_name = tcp
> iface.initiatorname = <empty>
> node.discovery_address = 192.168.20.4
> node.discovery_port = 3260
> node.discovery_type = send_targets
> node.session.initial_cmdsn = 0
> node.session.initial_login_retry_max = 8
> node.session.xmit_thread_priority = -20
> node.session.cmds_max = 128
> node.session.queue_depth = 32
> node.session.auth.authmethod = None
> node.session.auth.username = <empty>
> node.session.auth.password = <empty>
> node.session.auth.username_in = <empty>
> node.session.auth.password_in = <empty>
> node.session.timeo.replacement_timeout = 120
> node.session.err_timeo.abort_timeout = 15
> node.session.err_timeo.lu_reset_timeout = 20
> node.session.err_timeo.host_reset_timeout = 60
> node.session.iscsi.FastAbort = Yes
> node.session.iscsi.InitialR2T = No
> node.session.iscsi.ImmediateData = Yes
> node.session.iscsi.FirstBurstLength = 262144
> node.session.iscsi.MaxBurstLength = 16776192
> node.session.iscsi.DefaultTime2Retain = 0
> node.session.iscsi.DefaultTime2Wait = 2
> node.session.iscsi.MaxConnections = 1
> node.session.iscsi.MaxOutstandingR2T = 1
> node.session.iscsi.ERL = 0
> node.conn[0].address = 192.168.20.4
> node.conn[0].port = 3260
> node.conn[0].startup = manual
> node.conn[0].tcp.window_size = 524288
> node.conn[0].tcp.type_of_service = 0
> node.conn[0].timeo.logout_timeout = 15
> node.conn[0].timeo.login_timeout = 15
> node.conn[0].timeo.auth_timeout = 45
> node.conn[0].timeo.noop_out_interval = 5
> node.conn[0].timeo.noop_out_timeout = 5
> node.conn[0].iscsi.MaxRecvDataSegmentLength = 262144
> node.conn[0].iscsi.HeaderDigest = None
> node.conn[0].iscsi.DataDigest = None
> node.conn[0].iscsi.IFMarker = No
> node.conn[0].iscsi.OFMarker = No
> # END RECORD
> root@test-03:~# 
> 
> I have found code in nova to do this kind of discovery, but it appears
> deprecated in favor of passing the target location directly through
> nova's messaging layer.  I'm wondering if discovery should be attempted
> as a fall-back if the initiator fails to find records directly.
> 
> ** Affects: nova
>     Importance: Undecided
>         Status: New
> 
> -- 
> You received this bug notification because you are subscribed to
> OpenStack Compute (nova).
> https://bugs.launchpad.net/bugs/922232
> 
> Title:
>  Volumes fail to attach without discovery using tgt
> 
> Status in OpenStack Compute (Nova):
>  New
> 
> Bug description:
>  I'm not sure if this is a general bug or specific to the tgt iscsi
>  helper (will compare with ietd soon)
> 
>  Attaching a volume to an instance results in the following errors in
>  nova-compute.log on a libvirt compute node:
>  http://paste.ubuntu.com/817916/
> 
>  Manually walking thru the initiator commands on the compute node ends
>  in the same results, mainly:
> 
>  # iscsiadm -m node -T iqn.2010-10.org.openstack:volume-00000001 -p 192.168.20.4:3260
>  iscsiadm: no records found!
> 
>  It's not until I send a discovery to the target can I list any
>  records, which (I assume) is the first step toward a successful volume
>  attachment in nova.
> 
>  root@test-03:~# iscsiadm -m discovery -t sendtargets -p 192.168.20.4:3260
>  192.168.20.4:3260,1 iqn.2010-10.org.openstack:volume-00000001
>  root@test-03:~# iscsiadm -m node -T iqn.2010-10.org.openstack:volume-00000001 -p 192.168.20.4:3260
>  # BEGIN RECORD 2.0-871
>  node.name = iqn.2010-10.org.openstack:volume-00000001
>  node.tpgt = 1
>  node.startup = manual
>  iface.hwaddress = <empty>
>  iface.ipaddress = <empty>
>  iface.iscsi_ifacename = default
>  iface.net_ifacename = <empty>
>  iface.transport_name = tcp
>  iface.initiatorname = <empty>
>  node.discovery_address = 192.168.20.4
>  node.discovery_port = 3260
>  node.discovery_type = send_targets
>  node.session.initial_cmdsn = 0
>  node.session.initial_login_retry_max = 8
>  node.session.xmit_thread_priority = -20
>  node.session.cmds_max = 128
>  node.session.queue_depth = 32
>  node.session.auth.authmethod = None
>  node.session.auth.username = <empty>
>  node.session.auth.password = <empty>
>  node.session.auth.username_in = <empty>
>  node.session.auth.password_in = <empty>
>  node.session.timeo.replacement_timeout = 120
>  node.session.err_timeo.abort_timeout = 15
>  node.session.err_timeo.lu_reset_timeout = 20
>  node.session.err_timeo.host_reset_timeout = 60
>  node.session.iscsi.FastAbort = Yes
>  node.session.iscsi.InitialR2T = No
>  node.session.iscsi.ImmediateData = Yes
>  node.session.iscsi.FirstBurstLength = 262144
>  node.session.iscsi.MaxBurstLength = 16776192
>  node.session.iscsi.DefaultTime2Retain = 0
>  node.session.iscsi.DefaultTime2Wait = 2
>  node.session.iscsi.MaxConnections = 1
>  node.session.iscsi.MaxOutstandingR2T = 1
>  node.session.iscsi.ERL = 0
>  node.conn[0].address = 192.168.20.4
>  node.conn[0].port = 3260
>  node.conn[0].startup = manual
>  node.conn[0].tcp.window_size = 524288
>  node.conn[0].tcp.type_of_service = 0
>  node.conn[0].timeo.logout_timeout = 15
>  node.conn[0].timeo.login_timeout = 15
>  node.conn[0].timeo.auth_timeout = 45
>  node.conn[0].timeo.noop_out_interval = 5
>  node.conn[0].timeo.noop_out_timeout = 5
>  node.conn[0].iscsi.MaxRecvDataSegmentLength = 262144
>  node.conn[0].iscsi.HeaderDigest = None
>  node.conn[0].iscsi.DataDigest = None
>  node.conn[0].iscsi.IFMarker = No
>  node.conn[0].iscsi.OFMarker = No
>  # END RECORD
>  root@test-03:~# 
> 
>  I have found code in nova to do this kind of discovery, but it appears
>  deprecated in favor of passing the target location directly through
>  nova's messaging layer.  I'm wondering if discovery should be
>  attempted as a fall-back if the initiator fails to find records
>  directly.
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nova/+bug/922232/+subscriptions