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デバイスの入手方法に関するアイデアはありますか?
TwinStrataは私のクリネットのiqn番号を必要としました。これはここにあります:
less /etc/iscsi/initiatorname.iscsi
サーバーの変更が行われたら、クライアントのiscsiサービスを再起動すると、/ dev/sdaが表示されました。
検出後、ターゲットにログインする必要があります。
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ターゲットに接続するにはどうすればよいですか?
私も同じ問題を抱えていました。私はそれがすべてターゲット構成に関するものであると結論づけます。
/ 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に設定されます。これをサーバーマネージャーのバグとして分類します。
私は非常に似たような状況に遭遇し、ここにあるヒントに感謝します。私の場合、/ etc/iscsi/initiatorname.iscsiファイルのIQNを変更し、iscsiを何度か再起動しましたが、nutはまだ接続できませんでした。
私の答えはiscsidを再起動することでした( "d"に注意してください)。具体的には、iscsiとiscsidの両方を再起動する必要がありました。
# service iscsi stop
# service iscsid stop
# service iscsid start
# service iscsi start
私はこれと同じ問題を抱えていましたが、それがターゲットの問題であることが判明しました。
私の場合(ターゲットはNetApp)、イニシエーターグループをLUNにマップするのを忘れていました。