最近、UEFIブートで多くの問題が発生しています。テストに使用しているVMが2つあります。 1つはDHCP/TFTP(CentOS 7)を実行しており、もう1つはUEFIブートに設定されたクライアントです。レガシーブートでこれをテストしましたが、イメージをブートしてプルすることができます。ただし、UEFIクライアントがDHCP割り当てを取得しているようには見えません。両方のマシンが同じ仮想ワイヤ(ポートグループ)上にあるため、ネットワークの問題が発生することはありません。以前に行った同じ問題が発生していない別の設定をミラーリングしたので、少し途方に暮れています。何か小さなものが足りない気がするので、気づいたら教えていただければ幸いです!ありがとうございます!
テスト環境のpcapを取得し、サーバーからのDHCP応答を確認できます。
# tcpdump -enli ens192 port 67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens192, link-type EN10MB (Ethernet), capture size 262144 bytes
12:45:51.742154 00:0c:29:ae:ff:e7 > Broadcast, ethertype IPv4 (0x0800), length 389: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0c:29:ae:ff:e7, length 347
12:45:51.742436 00:0c:29:7a:7c:27 > Broadcast, ethertype IPv4 (0x0800), length 342: 132.0.101.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300
12:46:07.742311 00:0c:29:ae:ff:e7 > Broadcast, ethertype IPv4 (0x0800), length 389: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0c:29:ae:ff:e7, length 347
12:46:07.742506 00:0c:29:7a:7c:27 > Broadcast, ethertype IPv4 (0x0800), length 342: 132.0.101.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300
その後、ログでDHCPが実際に起動サーバーにアドレスを提供していることがわかります(これはNTPにアクセスできないオフライン環境であることに注意してください)。
Aug 17 12:42:23 stager named[1148]: error (network unreachable) resolving './NS/IN': 2001:500:12::d0d#53
Aug 17 12:42:23 stager named[1148]: error (network unreachable) resolving '3.centos.pool.ntp.org/AAAA/IN': 2001:500:12::d0d#53
Aug 17 12:42:23 stager named[1148]: error (network unreachable) resolving '3.centos.pool.ntp.org/A/IN': 2001:500:12::d0d#53
Aug 17 12:42:28 stager dhcpd: DHCPDISCOVER from 00:0c:29:ae:ff:e7 via ens192
Aug 17 12:42:28 stager dhcpd: DHCPOFFER on 132.0.101.11 to 00:0c:29:ae:ff:e7 via ens192
とにかく、クライアントは実際に起動することはなく、あきらめるまで下の画面に留まります:
私のdhcpd.conf:
max-lease-time 7200;
ddns-update-style none;
authoritative;
log-facility local7;
allow booting;
allow bootp;
option client-system-Arch code 93 = unsigned integer 16;
class "pxeclients" {
match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
#TFTP Server
option tftp-server-name "132.0.101.2";
next-server 132.0.101.2;
if option client-system-Arch = 00:00 {
filename = "bios/pxelinux.0";
} elsif option client-system-Arch = 00:07 {
filename = "images/esxi6.7/efi/boot/bootx64.efi";
option boot-size 344;
}
}
subnet 132.0.101.0 netmask 255.255.255.0 {
option routers 132.0.101.1;
option domain-name-servers 132.0.101.2;
range 132.0.101.11 132.0.101.99;
}
DHCPの クライアントシステムアーキテクチャタイプオプション は、PXEEFIクライアントのいくつかのアーキテクチャを定義します。それらのうち、2つが興味深いです:
Type Architecture Name ---- ----------------- [...] 7 EFI BC [...] 9 EFI x86-64
EFI BC
は ドライバー用のプロセッサーに依存しないバイトコードの実装 であり、UEFIPXEブートでよく使用されます。
現在、最近のVMwareドキュメントでは、フィルターはタイプ00:07
または00:09
の両方を受け入れています。例:this PDFドキュメント PXEを使用したESXiのインストール-VMware vSphere 6. 、または DHCP構成のサンプル 、どちらも次のものが含まれます。
if option client-system-Arch = 00:07
or option client-system-Arch = 00:09
{
この期待から、VMwareのエミュレートされたUEFIファームウェアは00:09
を送信し、より一般的な00:07
アーキテクチャタイプは送信しないと思われるため、DHCPサーバーに両方を配置することをお勧めします。
更新:OPのコメントによると、x86-64ハードウェア(または仮想)ベンダーによっては、EFI実装が異なる可能性があるため、タイプ00:07
またはタイプ00:09
を送信するようです。
タイプ00:09
を追加して、ESXiクライアントにTFTPが提供されているかどうかを確認する必要があります。
私にはこの理論を検証する手段がありません。