Volumes fail to attach without discovery using tgt
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
Medium
|
Vish Ishaya | ||
nova (Ubuntu) |
Fix Released
|
High
|
Adam Gandelman |
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://
Manually walking thru the initiator commands on the compute node ends in the same results, mainly:
# iscsiadm -m node -T iqn.2010-
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-
root@test-03:~# iscsiadm -m node -T iqn.2010-
# BEGIN RECORD 2.0-871
node.name = iqn.2010-
node.tpgt = 1
node.startup = manual
iface.hwaddress = <empty>
iface.ipaddress = <empty>
iface.iscsi_
iface.net_ifacename = <empty>
iface.transport
iface.initiatorname = <empty>
node.discovery_
node.discovery_port = 3260
node.discovery_type = send_targets
node.session.
node.session.
node.session.
node.session.
node.session.
node.session.
node.session.
node.session.
node.session.
node.session.
node.session.
node.session.
node.session.
node.session.
node.session.
node.session.
node.session.
node.session.
node.session.
node.session.
node.session.
node.session.
node.session.
node.session.
node.conn[
node.conn[0].port = 3260
node.conn[
node.conn[
node.conn[
node.conn[
node.conn[
node.conn[
node.conn[
node.conn[
node.conn[
node.conn[
node.conn[
node.conn[
node.conn[
# 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.
Changed in nova: | |
assignee: | nobody → Adam Gandelman (gandelman-a) |
status: | New → In Progress |
Changed in nova (Ubuntu): | |
importance: | Undecided → High |
assignee: | nobody → Adam Gandelman (gandelman-a) |
Changed in nova (Ubuntu): | |
status: | New → Fix Released |
Changed in nova: | |
milestone: | none → essex-4 |
importance: | Undecided → Medium |
Changed in nova: | |
status: | Fix Committed → Fix Released |
Changed in nova: | |
milestone: | essex-4 → 2012.1 |
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: paste.ubuntu. com/817916/ 10.org. openstack: volume- 00000001 -p 192.168.20.4:3260 10.org. openstack: volume- 00000001 10.org. openstack: volume- 00000001 -p 192.168.20.4:3260 10.org. openstack: volume- 00000001 ifacename = default _name = tcp address = 192.168.20.4 initial_ cmdsn = 0 initial_ login_retry_ max = 8 xmit_thread_ priority = -20 cmds_max = 128 queue_depth = 32 auth.authmethod = None auth.username = <empty> auth.password = <empty> auth.username_ in = <empty> auth.password_ in = <empty> timeo.replaceme nt_timeout = 120 err_timeo. abort_timeout = 15 err_timeo. lu_reset_ timeout = 20 err_timeo. host_reset_ timeout = 60 iscsi.FastAbort = Yes iscsi.InitialR2 T = No iscsi.Immediate Data = Yes iscsi.FirstBurs tLength = 262144 iscsi.MaxBurstL ength = 16776192 iscsi.DefaultTi me2Retain = 0 iscsi.DefaultTi me2Wait = 2 iscsi.MaxConnec tions = 1 iscsi.MaxOutsta ndingR2T = 1 iscsi.ERL = 0 0].address = 192.168.20.4 0].startup = manual 0].tcp. window_ size = 524288 0].tcp. type_of_ service = 0 0].timeo. logout_ timeout = 15 0].timeo. login_timeout = 15 0].timeo. auth_timeout = 45 0].timeo. noop_out_ interval = 5 0].timeo. noop_out_ timeout = 5 0].iscsi. MaxRecvDataSegm entLength = 262144 0].iscsi. HeaderDigest = None 0].iscsi. D...
>
> 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://
>
> Manually walking thru the initiator commands on the compute node ends in
> the same results, mainly:
>
> # iscsiadm -m node -T iqn.2010-
> 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-
> root@test-03:~# iscsiadm -m node -T iqn.2010-
> # BEGIN RECORD 2.0-871
> node.name = iqn.2010-
> node.tpgt = 1
> node.startup = manual
> iface.hwaddress = <empty>
> iface.ipaddress = <empty>
> iface.iscsi_
> iface.net_ifacename = <empty>
> iface.transport
> iface.initiatorname = <empty>
> node.discovery_
> node.discovery_port = 3260
> node.discovery_type = send_targets
> node.session.
> node.session.
> node.session.
> node.session.
> node.session.
> node.session.
> node.session.
> node.session.
> node.session.
> node.session.
> node.session.
> node.session.
> node.session.
> node.session.
> node.session.
> node.session.
> node.session.
> node.session.
> node.session.
> node.session.
> node.session.
> node.session.
> node.session.
> node.session.
> node.conn[
> node.conn[0].port = 3260
> node.conn[
> node.conn[
> node.conn[
> node.conn[
> node.conn[
> node.conn[
> node.conn[
> node.conn[
> node.conn[
> node.conn[
> node.conn[