2番目NIC「正しく機能しない」ディスクレスサーバー2012

Question

私は（かなりの戦いの後）、NICのPXEからチェーンされたgPXEを介して起動されるMSソフトウェアiSCSIイニシエーターを介して実行されているディスクレスサーバー2012を持っています。

ただし、正常に起動しているので、別の問題があります（iSCSI HBAは、ヘアプルごとに魅力的になっています）。サーバーにはデュアルNICがあり、WindowsはSANに接続されているNICのみを受け入れているため、LAN接続がありません。

デバイスマネージャには両方のNICが表示されますが、LAN用のNICには感嘆符があり、プロパティには「Windowsがこのデバイスに必要なドライバを読み込めないため、このデバイスは正しく機能していません。（コード31）」と表示されます。

Windowsは明らかにあります 2つのポートが同一で、もう一方が機能しているため、適切なドライバーがあります。さらに、同じOSを同じハードウェアにローカルHDDにインストールしても、NICに問題はありません。より良いドライバーを探すように言うと、それはただ向きを変えて、ドライバーは大丈夫だと言っていますが、当然のことです。

この冒険の前の章のおかげで、私はここで何が起こっているのかを知っていると確信しています。

起動前プログラム（この場合はgPXE）は、iBFT（iSCSIブートファームウェアテーブル）をメモリに書き込む必要があります。メモリは、OS（この場合はWindows）によって取得されます。この表は、とりわけNICのリストを提供します。それぞれについて、PCIバスとデバイス番号、MACアドレス、およびIP情報を指定します。

そのソースコードを調べて（そしてiBFTをダンプするために開発した小さなツールによって）、gPXEは設計/怠惰によってiBFTに1つだけNIC）を書き込むことを知っています。そのうちの約240個。複数のNICを書き込んだとしても、他のgPXE/iPXEの問題により、UNDIのみのビルドを使用せざるを得なかったため、同じボートに乗ったままでした。つまり、他のNICについても認識していません。。

ここで起こっていることは、WindowsがiBFTを調べており、他のNICが独自のデバイス管理システムから存在することを知っているにもかかわらず）、それを使用できないと判断していることだと思います。それはiBFTにないので、私にはわかりませんなぜこれを行うでしょう。

Windowsが他のNICをiBFTにない場合でも使用するように誘導する方法はありますか？または、実際に正しく機能するiSCSIプリブートプログラムはありますか？または完全にありますか？別の説明？

Kevin · Answer

私はついにこれの底に到達し、それを機能させることができました。ただし、その過程で、Windows、gPXE、およびiPXEのiSCSIブート機能はすべて中途半端なものであるという結論に達しました。他の誰かに役立つ場合に備えて、私のために働いたアプローチを共有しますが、いくつかの注意点に注意してください：

これは貧弱な解決策です。 iSCSI HBAなどのハードウェアベースのソリューションは、パフォーマンスと堅牢性が向上し、セットアップがはるかに簡単になります。
このソリューションは、主にセットアップにディスクレスサーバーごとに手作業が多すぎるため、大規模な展開には適切に拡張できません。
この解決策はそれほど単純ではありません。より簡単な解決策があるかもしれません（明白なもの以外は、iSCSI HBAを使用してください）。それを知っている場合は、それを追加してください。複製できる場合は、答えをマークします。
この解決策は醜い、醜いハックです。自己責任で使用してください!!

先に進む前に、「NIC」と言うときはいつでも、Windowsが単一の「デバイス」と見なすものを指していることを明確にしておきますが、実際には、実際のNICのいくつかのポートの1つにすぎない可能性があります。この用語は、iBFT標準自体とiPXE/gPXEの両方と一致しています。

Windowsは、iSCSIイニシエーターで起動すると、iBFTに関して非常に厄介な要件があります（「iSCSIブートソリューション」がWindowsブートローダーを呼び出す前にメモリに書き込むテーブルは、iSCSI LUへのアクセス方法を示します）。私はいくつかの「落とし穴」ルールをまとめることができました（これはあなたの特定の状況に当てはまるかもしれないし、当てはまらないかもしれません）：

A NICがiBFTにない場合、Windowsはそれを処理しません。それは、質問で与えられた症状を明らかにします。
IBFT内のNICのリストは、特定の順序で並べ替える必要があります。同じNIC上のテストサーバーに2つのNICポートしかないため、完全な詳細はわかりません。1つはPCI 08:04.0で、もう1つはPCI08:04.1でした。iBFTに=がリストされている場合NIC 08:04.1の前の08:04.0で、Windowsが狂った（標準には特定の順序を必要とするものがないことに注意してください）。
ISCSIターゲットはfirst NIC iBFTにリストされている）から到達可能である必要があります。これには、SANとLANを切り替える必要がある場合があります。上記のルールにより、ポート。
IBFTの最初のNICがWindowsを最初にインストールしたときと同じでない場合、クラッシュして再起動します。セットアップが最初に正しくなかった場合は、Windowsを再インストールする必要があります。。（「同じ」を構成するものについては肯定的ではありませんが、同じNICは間違いなく「同じ」ではありませんでした。）
NICセクションは、コントロールセクションにリストされているのと同じ順序でメモリ内に存在する必要があります。そうしないと、Windowsが狂ってしまいます（標準ではnot規定されていることに注意してください）。順序が一致している必要があります-繰り返しますが、これはWindowsが怠惰であるだけです。）

最初のルールはこすりです。 gPXE 1.0.0も、その後継であるiPXEの2013年1月31日のコミットも、ever複数のNICがわかっている場合でも、iBFTに複数のNICを書き込みません。私は彼らのソースコードを調べてこれを確認しました。

私のハッキーな解決策は、iPXEソースツリーを取得し、他のNICに対応する2番目のNICセクションをiBFTに書き込むようにプログラムを変更することでした。私のサーバーで（NIC私はnotから起動していました。）MACアドレスとPCIアドレスを配線しただけです。IPのものを配置する必要がないことがわかりました。 NICのセクションに入力します-すべてゼロのままにしておくと、後でWindowsが起動時に割り当てます（IP関連のものdoesはSAN NICですが、iPXEはすでにそれを行うようにコーディングされています。）

#defineを使用することで、実際のアドレスを変更するたびにソースコードを調べなくても、便利な場所に入力できます。

この変更を行う場合は、NICセクションのヘッダーにインデックスバイトがあることに注意してください。iPXEコードは（structで指定されていますが）これらに影響を与えません。、複数のNICを書き込むことはありますが、2番目のNICを書き込む場合は、そのインデックスバイトを1に設定する必要があります。そうしないと、Windowsは満足しません。

このソリューションの明らかな大きな欠点は、サーバーごとにiPXEを再コンパイルし、これらの個別のバージョンのiPXEをTFTPサーバーに保持し、サーバーごとに異なるブートプログラムを発行するようにPXEサーバーを構成する必要があることです。

LinuxディストリビューションとGNU開発ツール。iBFT形式が指定されていますこことともに、最初の変更を行うには、Cプログラミングの知識が必要です。

ここに変更を投稿できればいいのですが、実際には、ipxe.orgWebサイトにだまされてダウンロードさせられた非常に古いバージョンを変更することになりました。（どうやら、それらは安定したリリースにタグを付けることはありません。それ以来、masterブランチのすべてのリリースが安定していることを学びました。）私は、そのような古いバージョンを使用することを誰にも勧めたくありません。

最新バージョンにも同じ制限があります。これを開発リストに転送するので、うまくいけば修正されます。