web-dev-qa-db-ja.com

CentOS iscsiイニシエーターにはセッションがありますが、ブロックデバイスがありません

CentOSにscsi-target-utilsパッケージをインストールし、それを使用して検出を実行しました。発見は私に活発なセッションを与えました。 iscsiサービスを再起動しましたが、新しいデバイスが表示されません（fdisk -l）。/var/log/messagesで、接続が現在動作していることがわかります。

これをさらにデバッグする方法がわかりません。誰かがこれを修正するように私に指示できますか？

発見：

iscsiadm -m discovery -t sendtargets -p 192.168.0.155

戻り値：

192.168.0.155:3260,-1 iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3

実際に機能したことを確認するだけです：

iscsiadm -m session

戻り値

tcp: [1] 192.168.0.155:3260,1 iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3

指示に従って、再起動します。

service iscsi restart

/ var/log/messageに書き込まれる出力

Stopping iscsi: Sep 20 12:14:22 localhost kernel: connection1:0: detected conn error (1020)
                                                           [  OK  ]
Starting iscsi: Sep 20 12:14:22 localhost kernel: scsi1 : iSCSI Initiator over TCP/IP
Sep 20 12:14:22 localhost iscsid: Connection1:0 to [target: iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3, portal: 192.168.0.155,3260] through [iface: default] is shutdown.
Sep 20 12:14:22 localhost iscsid: Could not set session2 priority. READ/WRITE throughout and latency could be affected.
                                                           [  OK  ]
[root@db iscsi]# Sep 20 12:14:23 localhost iscsid: Connection2:0 to [target: iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3, portal: 192.168.0.155,3260] through [iface: default] is operational now

ログインコマンドを実行しました。

iscsiadm -m node -T iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3 -p 192.168.0.155 -l

エラーはなく、ロギングは発生しませんでした。

次に、「fdisk -l | egrep dev」の出力をiscsiセッションありとなしの両方で比較しました。違いはありません。/etc/mtabだけを見ることができると思います。 iscsiデバイスの入手方法に関するアイデアはありますか？

centosiscsicentos6
4
jcalfee314

TwinStrataは私のクリネットのiqn番号を必要としました。これはここにあります：

less /etc/iscsi/initiatorname.iscsi

サーバーの変更が行われたら、クライアントのiscsiサービスを再起動すると、/ dev/sdaが表示されました。

2
jcalfee314

検出後、ターゲットにログインする必要があります。

iscsiadm -m node -T iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3 -p 192.168.0.155:3260 -l

参照： iSCSIターゲットを永続的にマウントするiSCSIイニシエーターとしてシステムを構成する
LinuxでiSCSIターゲットを使用する方法
LinuxコンソールからiSCSIターゲットに接続するにはどうすればよいですか？

1
Aaron Copley

私も同じ問題を抱えていました。私はそれがすべてターゲット構成に関するものであると結論づけます。

/ dev /にマウントされたものがないことを除いて、すべてのログメッセージは問題なく見えました。ターゲットとしてWindows Server 2012 R2を使用していて、既存の仮想ディスク（VHDX）をUbuntuに提供しようとしていました。そのVHDXは以前、独自のVMFS形式でVMWare ESXiに提供され、使用されていました。接続が確立された後、何らかの理由でUbuntuがこれを処理できなかったようです。まったく同じ設定で新しい仮想ディスクとその新しいターゲットを作成したら、iscsiadmで新しいセッションを作成すると、最終的にブロックデバイスができました。その後、他のシナリオをテストしたところ、iSCSI仮想ディスクとしてインポートされたVHDXファイルのコピーから作成されたターゲットでも同じことが起こることがわかりました。しかし、それらを拡張すると（それらはシンプロビジョニングされていたため）、サーバーマネージャーでエラーが発生するため、明らかに壊れています。したがって、ターゲットが何らかの形で壊れている場合、open-iscsiはブロックデバイスを提供しません。

唯一の解決策は、この問題が発生したときに、構成全体をやり直すことです（そして、はい、受け入れられた回答に記載されているように、ターゲットの構成でイニシエーターIDを設定することを忘れないでください）。

壊れたターゲットとして数えられるものに関するメモと同じように、最終的にターゲットが壊れていることがわかりました。これは、FileIntegrityビットがEnabled = Trueに設定されている場合、ReFSボリューム上のVHDXファイルは使用できないためです。悲しいことに、VHD/VHDXファイルをReFSボリュームにコピーしようとすると、Hyper-Vのみがエラーを生成しますが、iSCSIターゲットディスクのセットアップに関するセクションのサーバーマネージャーはエラーを生成しません。新しいディスク用にiSCSIターゲットウィザードで作成されたフォルダー（iscsivirtualdisksと呼ばれます）のFileIntegrityビットは[有効]に設定されているため、このフォルダーで作成されたすべてのファイル（そこにコピーするVHDXファイル）も、そのビットがEnabled = Trueに設定されます。これをサーバーマネージャーのバグとして分類します。

1
Anton Kaiser

私は非常に似たような状況に遭遇し、ここにあるヒントに感謝します。私の場合、/ etc/iscsi/initiatorname.iscsiファイルのIQNを変更し、iscsiを何度か再起動しましたが、nutはまだ接続できませんでした。

私の答えはiscsidを再起動することでした（ "d"に注意してください）。具体的には、iscsiとiscsidの両方を再起動する必要がありました。

# service iscsi stop
# service iscsid stop
# service iscsid start
# service iscsi start
1
msmcknight

私はこれと同じ問題を抱えていましたが、それがターゲットの問題であることが判明しました。

私の場合（ターゲットはNetApp）、イニシエーターグループをLUNにマップするのを忘れていました。

0
Pyzo