web-dev-qa-db-ja.com

VMware VM WDSサーバーに対するPXEブート中に使用されるプロトコルを決定するものは何ですか？

おはようございます

私は自分の環境にWindowsDeployment Serverを正常に実装し、Microsoft Deployment Toolkit（v8450）を使用してUEFIとレガシーBIOSをサポートするx86とx64の両方のブートイメージを構築し、両方の物理マシンを正常にPXEブートすることができました（HP Z4）および仮想マシン（ESXi 6.5ホストで実行されているVMバージョン13 ）。さらに、関連するDHCPベンダークラスとポリシーを作成して、適切なブートファイルが適切なPXEクライアント（つまり、UEFIとBIOS）に確実に提供されるようにしました。

とはいえ、UEFI（セキュアブートを有効にして）を使用して起動すると、2つのことがわかりました（2つ目は懸念があるため、この質問を投稿します）：

  1. ブートプロセス中、物理マシンはWDSサーバーに正常に接続し、約6秒でブートイメージをプルダウンし、その後、約6〜8分でOSのインストールを完了します。

  2. ブートプロセス中に、仮想マシンはWDSサーバーに正常に接続し、ブートイメージをプルダウンします。ただし、ブートイメージを取得するのに45分から1時間以上かかります。その後、OSのインストールは物理ボックスとほぼ同じ時間（約8分）で完了します。

トラブルシューティングを行うために、WDSサーバーでNICパフォーマンスに影響する技術的な問題が発生していないことを確認しました。VMのNIC構成を確認し、 E1000Eアダプタタイプ-を使用するように変更したので、代わりにVMXNET 3アダプタタイプを使用するように変更しました。これにより、わずかな改善が行われました。

そこで、Wiresharkパケットキャプチャを実行して、物理マシンとVMがWDSサーバーと通信している方法で何か違うものが見えるかどうかを確認することにしました。唯一目立ったのは、私にとっては次のとおりです。

  1. 物理マシンはTFTPプロトコルを使用しました
  2. 仮想マシンはUDPプロトコルを使用しました

そのため、仮想マシンにTFTPよりもUDPプロトコルを優先するように指示する設定があるかどうか誰かが知っていますか？ PXE-という事実以外に、VMwareのドキュメントで決定的なものは何も見つかりませんでした。 VMの起動が可能であり、サポートされていました。

長い物語をありがとう、そして私の謝罪、どんな援助も間違いなくありがたいです。

windowsvmware-esxipxe-bootwds
2
Kismet Agbasi

したがって、この問題が発生した場合の解決策は、 "ramdisktftpblocksize"と "ramdisktftpwindowsize"を調整することでした。 WDS RemoteInstallブートフォルダー内のそれぞれのアーキテクチャー（、つまりx86またはx64）のブート構成データ（BCD）ファイル内の設定。その後、WDSサービスを再起動しました。現在、約400MBのブートイメージを使用して、仮想マシンで約10〜15秒、物理マシンで約6〜10秒のブートイメージのロード時間が表示されています。

私が気付いたのは、これにより断片化されたIPパケットが作成されることだけですが、それらはとにかく再構築されます。そのため、頻度と時間に基づいてエンドユーザーやネットワークへの影響はほとんどないので、あまり気になりません。イメージング用のPXEブートシステムになります。ただし、それが問題になる場合は、別の解決策を探してください。

私の環境では、パスは次のとおりでした（もちろん異なる可能性があるので、それに応じて調整してください）：

For 32-bit (x86):  "F:\SCCM\RemoteInstall\Boot\x86\default.bcd"
For 64-bit (x64):  "F:\SCCM\RemoteInstall\Boot\x64\default.bcd"

注意：明らかな理由で、変更を加える前にdefault.bcdファイルのバックアップを作成してください（私は願っています）。

このソリューションを実装するために私がしたことは次のとおりです：

  1. PXEサーバーでWDS管理コンソールを開きます（私の場合はSCCM Windows展開サービスの役割を実行しているサーバー）および[〜＃〜]サーバーを停止します[〜＃〜]WDSサービスを停止することもできます-しかし、私は前者（よりクリーンなアプローチであるため、IMHO）。
  2. 管理コマンドプロンプトウィンドウを起動します（PowerShellコンソールを使用するように誘惑されないでください。BCDEditコマンドを操作する運があまりありませんでした）。
  3. 別のWindowsエクスプローラーウィンドウで、適切な "default.bcd"ファイルを見つけ、そのパスをメモするか、 "SHIFT + Right-Click"and "Copy as path"。
  4. WDSサーバーが停止し、default.bcdファイルへのパスが手元にある状態で、コマンドプロンプトに戻り、次のコマンドを入力します（x86またはx64必要に応じて）：
    • 次のコマンドで現在のブートストアパラメータを一覧表示します：
      • bcdedit /enum all /store F:\SCCM\RemoteInstall\Boot\x86\default.bcd
    • TFTPウィンドウサイズを8の値に設定します：
      • bcdedit /store F:\SCCM\RemoteInstall\Boot\x86\default.bcd /set {68d9e51c-a129-4ee1-9725-2ab00a957daf} ramdisktftpwindowsize 8
    • TFTPブロックサイズを16384の値に設定します：
      • bcdedit /store F:\SCCM\RemoteInstall\Boot\x86\default.bcd /set {68d9e51c-a129-4ee1-9725-2ab00a957daf} ramdisktftpblocksize 16384
    • 現在のブートストアパラメータを再度リストし、変更がそこにあることを確認します：
      • bcdedit /enum all /store F:\SCCM\RemoteInstall\Boot\x86\default.bcd
  5. WDS管理コンソールに戻り、WDSサーバーを起動します

  6. 次のコマンドを使用して、変更を加えてブートファイルを再構築するようにWDSサーバーに通知します。**

    - sc control wdsserver 129

以上です。これらの変更により、PXEサーバーでWiresharkを起動し、仮想マシンをpxeブートすることができました。 Wiresharkで見たとき、最初の会話は "TFTPWindowSize = 4"および "TFTPBlockSize =で始まるのがわかりました。 1456 "しかし、ブートローダー自体がダウンロードを開始した直後に、設定した値が有効になる再ネゴシエーションが表示されました。そのとき、VM load]が表示されました。 10〜15秒以内のブートイメージ。

先に述べたように、約8個の「フラグメント化されたIPプロトコル」パケットを見ましたが、それらはすべて再構築され、最終目標に加えて、仮想マシンと物理マシンの両方が高速に起動し、OSが正常にインストールされました。

この情報が誰かに役立つことを願っています-本を書いてすみません...笑。

次の投稿へのクレジット：https://blog.uvm.edu/jgm/2010/11/04/tuning-Microsoft- pxe-tftp /

1
Kismet Agbasi