OpenStack Compute (Nova)

Comment 1 for bug 922232

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