MENU

Hyper‑Vの特定VMだけネットワークが切断される原因と解決策｜Windows Server 2022・Broadcom BCM57416での実践手順

Hyper-V

Hyper‑V 上の特定 VM だけが突然ネットワークを失う――しかもホスト再起動で一時復旧してしまう――この“つかみどころのない”障害は、ドライバー／ファームウェアの不整合とオフロード機能の相性、そして vSwitch と物理 NIC の組み合わせが主因であることが多いです。本記事は、Windows Server 2022 と HPE DL380 Gen11（Broadcom BCM57416）という実環境を例に、再現性の低い切断を止め切るための実践手順と、現場で即使えるコマンド／チェック表をまとめました。

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

ケース概要（実環境の整理）

ハイパーバイザーWindows Server 2022 Standard（Hyper‑V）
ハードウェアHPE DL380 Gen11 / Broadcom BCM57416 10GbE ×2（想定）
VM構成VM1：ドメイン コントローラ（正常）／ VM2：アプリ&SQLサーバー（ホスト名：Sapphire2024）
症状Sapphire2024 のみが不定期に切断。ゲストの仮想 NIC は「接続なし」。DC では再現しない。
暫定回復ホスト再起動→VM 自動起動で復旧（再発あり）
実施済みWindows Update、HPE SPP/ファーム更新、外部 vSwitch の再作成

先に結論（要点のショートリスト）

  • 最優先：Broadcom BCM57416 の ドライバー／ファームウェアをサーバーモデルと OS に適合させ、両者を同一世代にそろえる（汎用ドライバーは不可）。
  • 次点：ホスト pNIC とゲスト vNIC の オフロード／キュー機能（VMQ, vRSS, LSO, RSC）を段階的に無効化して再発が止まる組み合わせを確定。
  • 切り分け：外部 vSwitch を 物理ポート単位で分離し、Sapphire2024 を専用の vSwitch に接続。NIC チーミングは基本オフで検証。
  • 再発監視＆即時復旧：ホスト再起動なしで Disconnect‑VMNetworkAdapter / Connect‑VMNetworkAdapter による即時復旧スクリプトを常備。

なぜ起きるのか（技術背景）

Hyper‑V のネットワークは、外部 vSwitch と pNIC（物理 NIC） の上に複数の vNIC（ゲスト側） を多重化します。高負荷下では、パケット分散・オフロード（VMQ, vRSS, LSO/RSC, IPsec Offload 等）が効率化に寄与する一方、ドライバー世代の差や 機能同士の相性が悪いと、キュー枯渇・割り込み競合・セグメント再構成の不一致などがトリガーになり、特定 VM の vNIC が “接続なし” 状態へ落ちることがあります。
とりわけ Broadcom NIC は、ドライバーとファームウェアのペアリング（同一系統の組み合わせ）や VMQ/vRSS のパラメータの整合性がシビアで、小規模～中規模環境で“過剰最適化”が逆に不安定化を招く例が見られます。

対策ロードマップ（優先度順で確実に潰す）

1. NIC ドライバー／ファームウェアの適合確認と統一

Windows Update の汎用ドライバーではなく、HPE SPP / SoftPaq 提供の BCM57416 向け正式版に統一します。ドライバー・ファームウェアの組み合わせは、HPE DL380 Gen11 × Windows Server 2022 のサポートマトリクスと一致している必要があります。世代違いの組み合わせは避け、両方を同一世代にそろえるのが鉄則です。

確認コマンド（ホスト）

# 物理NICの基本情報
Get-NetAdapter | Sort-Object Name | Format-Table Name, Status, LinkSpeed, DriverInformation

# 署名ドライバーの詳細（Broadcom を抽出）

Get-CimInstance Win32_PnPSignedDriver |
Where-Object { $_.DeviceName -match 'Broadcom|BCM|NetXtreme' } |
Select-Object DeviceName, DriverVersion, DriverDate, Manufacturer |
Format-Table -Auto

# ファームの世代は iLO/コンソールやベンダーツールで合わせる（ここでは表示対象外）

ポイント

  • SPP の適用は iLO 経由のメンテナンス時間で実施。適用後は必ず vSwitch のバインド確認を行う。
  • Windows の「ドライバー更新」で汎用版に戻らないよう、自動更新の除外や SoftPaq の固定を検討。

2. オフロード系機能の段階的無効化（再発が止まるポイントを見つける）

無効化はホスト→ゲストの順で進めると切り分けが明確です。まずはホストの pNIC 側で VMQ/LSO/RSC/RSS を止め、それで改善するかを確認。止まれば“ホスト側の設定が原因”と判断できます。止まらない場合は、ゲスト vNIC（Sapphire2024 内）で TCP チェックサム／LSO を停止し、再検証します。

ホスト側（pNIC）の例

# VMQを無効化（再起動不要だが、切断中は接続やり直し推奨）
Disable-NetAdapterVmq -Name "NIC10G-1"

# RSS（受信側スケーリング）を無効化

Set-NetAdapterRss -Name "NIC10G-1" -Enabled $false

# LSO/RSC を無効化（送受信のセグメント集約）

Disable-NetAdapterLso -Name "NIC10G-1"
Disable-NetAdapterRsc -Name "NIC10G-1"

# IPsec Offload があれば無効化（表示名により異なる）

Get-NetAdapterAdvancedProperty -Name "NIC10G-1" |
Where-Object {$*.DisplayName -match 'IPsec|IP Security'} |
ForEach-Object { Set-NetAdapterAdvancedProperty -Name "NIC10G-1" -DisplayName $*.DisplayName -DisplayValue "Disabled" }

# 現在値の一覧

Get-NetAdapterAdvancedProperty -Name "NIC10G-1" | Sort-Object DisplayName

ゲスト側（Sapphire2024 内の vNIC）の例

# TCP チェックサム／LSO の無効化
Disable-NetAdapterChecksumOffload -Name "Ethernet"
Disable-NetAdapterLso -Name "Ethernet"

# （Hyper‑V ホストから実施）特定VMの vRSS/VMQ 重み調整

Set-VMNetworkAdapter -VMName "Sapphire2024" -VrssEnabled $false
Set-VMNetworkAdapter -VMName "Sapphire2024" -VmqWeight 0

運用のコツ：一気に全部オフではなく、“1項目ずつ”無効化→最低24時間の観察→再発の有無で前進／巻き戻しを判断。再発が止まった時点の組み合わせを「安定構成の暫定解」として記録します。

3. イベントログで発火点を特定する

切断時刻に一致するエラー／警告の有無で、ホスト側の Hyper‑V/NDIS が落ちているのか、ゲストの netvsc（Hyper‑V 合成 NIC ドライバー） がリンクダウンしているのかを切り分けます。

  • ホスト：Hyper‑V‑VMMS、Hyper‑V‑Worker、Microsoft‑Windows‑Hyper‑V‑VMSwitch、System（NDIS/Netwtw/BNXTND 等）
  • ゲスト：System（NetVsc / NDIS / Tcpip / vmnetadapter）

周辺10分のログ抽出スクリプト例

$t = Get-Date "2025-10-31T10:15:00"   # 例：発生時刻
$span = New-TimeSpan -Minutes 10
Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$t-$span; EndTime=$t+$span} |
  Where-Object { $_.ProviderName -match 'NDIS|NetVsc|Tcpip|vmnetadapter|BNXT' } |
  Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message |
  Format-List

4. vNIC の作り直しと静的 MAC の付与

vNIC を一度削除→再作成し、静的 MAC アドレスを割り当てると安定することがあります。MAC 重複や MAC move（同一 MAC が別ポートへ頻繁に移動）を嫌うスイッチのポートセキュリティが有効な環境では特に有効です。

# vNIC の作り直し（接続先は後で再設定）
Remove-VMNetworkAdapter -VMName "Sapphire2024" -Name "Network Adapter" -Confirm:$false
Add-VMNetworkAdapter    -VMName "Sapphire2024" -Name "Network Adapter"

# 静的MACを Hyper‑V の準拠レンジで付与（00-15-5D-xx-xx-xx）

Set-VMNetworkAdapter -VMName "Sapphire2024" -Name "Network Adapter" -StaticMacAddress "00-15-5D-23-45-67"

# SR‑IOV の状態確認（サーバー/スイッチ/BIOSが対応しない場合は無効でOK）

Get-NetAdapterSriov

注意：「レガシー ネットワーク アダプター」は 第1世代（Gen1）VM のみで追加可能、PXE 起動用途が中心です。第2世代（Gen2）では使用できません。検証で一時利用する場合も、本番運用の恒久策としては推奨しません。

5. ドメイン コントローラ VM との設定差を潰す

同一ホスト上で DC が安定しているのは重要なヒントです。下表の観点で 完全一致させ、違いが原因でないかを潰します。

観点DCSapphire2024合わせ方
vSwitch 名／接続ポート外部‑A外部‑B?（要確認）同一または専用化
VMQ / vRSS / LSO / RSC有効/無効の組み合わせ不一致一致させて評価
帯域制御（MinimumBandwidth）未設定（無制限）設定あり？まずは無効化で観察
MAC 種別動的動的一時的に静的化
統合サービス（IC 項目）同一差分あり？同一に揃える

6. 外部 vSwitch と物理ポートの分離検証

BCM57416 の 10Gb ポートが2つあるなら、ポート1＝既存 vSwitch、ポート2＝新規 vSwitch を作って、Sapphire2024 を新規側へ接続します。これで物理ポート固有の問題（ポート/ケーブル/スイッチ側の設定）を切り分けられます。

# 既存の vSwitch を温存したまま、2本目のポートでテスト用 vSwitch を作成
New-VMSwitch -Name "vSwitch-Test" -NetAdapterName "NIC10G-2" -AllowManagementOS $true

# Sapphire2024 を新規 vSwitch へ

Connect-VMNetworkAdapter -VMName "Sapphire2024" -SwitchName "vSwitch-Test"

NIC チーミングの扱い：Hyper‑V では旧来の LBFO チーミングより、Switch Embedded Teaming（SET） が推奨です。トラブル切り分け中はまず 単一 NIC で安定性を確認し、必要に応じて SET で冗長化します。

# SET（スイッチ組み込みチーミング）の例：2ポートで1つの外部 vSwitch を冗長化
New-VMSwitch -Name "vSwitch-SET" -NetAdapterName "NIC10G-1","NIC10G-2" -EnableEmbeddedTeaming $true -AllowManagementOS $true

7. 即時復旧の標準手順（ホスト再起動は最終手段）

再起動せずに “リンクを差し替える” イメージで復旧できます。定型化して運用へ。

# 即時復旧（接続先を一旦切って戻す）
Disconnect‑VMNetworkAdapter -VMName "Sapphire2024"
Connect‑VMNetworkAdapter  -VMName "Sapphire2024" -SwitchName "外部スイッチ名"

# 併せて vNIC をリセット（ゲスト OS 側から）

Restart-NetAdapter -Name "Ethernet" -Confirm:$false

この手順で復旧する場合、物理層ではなく vSwitch/vNIC の論理層に原因が寄っている可能性が高いと判断できます。

8. 追加の推奨（安定化の“仕上げ”）

  • Windows Server 2022 の累積更新（CU）を最新化：ネットワークスタック／Hyper‑V 関連修正が含まれることがあるため、定期メンテの最優先項目に。
  • vRSS / Dynamic VMQ の調整：小規模環境ではオーバーヘッドになることがあるため、-VrssEnabled $false と -VmqWeight 0 でまずは無効化して評価。
  • QoS（帯域制御）を一旦外す：バックアップや DB メンテで瞬間的に帯域を食います。MinimumBandwidthAbsolute/Weight を未設定にして挙動確認。
  • スイッチポートの設定確認：Port‑Security（Sticky MAC）、Storm Control、BPDU Guard 等でポート遮断が起きていないか確認。MAC move が多いと抑止されることがあります。
  • 恒久化の奥の手：それでも再発する場合は 別メーカーの PCIe NIC を増設し vSwitch を移設、または SET/LBFO を完全解除した単一 NIC で安定性を検証。

検証の進め方（再現性が低い障害を“詰める”）

  1. 定常負荷とピークの可視化：Sapphire2024 のバックアップ時刻、メンテナンス、バッチ処理の時間帯を洗い出し、切断と相関がないか照合。
  2. DC と Sapphire2024 の差分を1つずつ潰す：同一 vSwitch / 同一ホスト設定で 48～72 時間観察。
  3. 機能は“全部オン”からスタートしない：既定が最適とは限りません。まずはオフロード類をシンプルにして安定化→必要な機能だけを 1つずつ戻す。
  4. 1変更＝1観察ウィンドウ：ログの“静けさ”も結果。無用な変更を重ねない。

トラブル切り分けの早見表

現象可能性が高い原因対処の第一歩
VM だけ「接続なし」、ホストや他 VM は正常vNIC/VMQ/vRSS の相性、ゲスト内オフロード不一致ゲスト側の LSO/Checksum を停止、-VrssEnabled $false
ホスト再起動で復旧しがちpNIC ドライバー／ファームの不整合、vSwitch‐pNIC バインドの不安定SPP/SoftPaq で世代統一、vSwitch を別ポートへ切替
切断直前に高負荷ジョブが動くVMQ キュー枯渇、RSC/LSO のフラグメント不整合VMQ 無効化、LSO/RSC 無効化で観察
稀にスイッチ側で MAC アドレス警告動的 MAC の頻繁な変更、ポートセキュリティ静的 MAC を付与、スイッチ設定を緩和

実運用に効くコマンド＆スクリプト集

ネットワーク機能の一括確認

# pNIC の状態とキュー/オフロードの可視化
Get-NetAdapter | ForEach-Object {
  $_
  Get-NetAdapterAdvancedProperty -Name $_.Name |
    Where-Object { $_.DisplayName -match 'VMQ|RSS|LSO|RSC|IPsec|VLAN|Interrupt|Offload' } |
    Sort-Object DisplayName
  ""
}

vNIC の健全性を点検（ホスト側から）

# VMごとの VMQ 重みと vRSS
Get-VMNetworkAdapter -VMName "Sapphire2024" |
  Select-Object VMName, Name, VmqWeight, VrssEnabled, MacAddress

# 帯域制御（MinimumBandwidth）をクリア

Set-VMNetworkAdapter -VMName "Sapphire2024" -MinimumBandwidthAbsolute 0

リンクダウン自動検知→再接続（タスクスケジューラで5分おきなど）

$vm = "Sapphire2024"
$switch = "外部スイッチ名"

try {
$adp = Get-VMNetworkAdapter -VMName $vm -ErrorAction Stop
if (-not $adp.Connected -or ($adp.Status -ne "Ok" -and $adp.Status -ne $null)) {
Write-EventLog -LogName Application -Source "HyperV-QuickFix" -EntryType Warning -EventId 7001 `
-Message "VM NIC issue detected. Reconnecting $vm"
Disconnect-VMNetworkAdapter -VMName $vm
Start-Sleep -Seconds 3
Connect-VMNetworkAdapter -VMName $vm -SwitchName $switch
}
} catch {

# エラーはイベントログへ

Write-EventLog -LogName Application -Source "HyperV-QuickFix" -EntryType Error -EventId 7002 `
-Message $_.Exception.Message
}

SQL ワークロード特有の注意点（Sapphire2024 を想定）

  • バックアップ窓の突発帯域：フル／差分／ログバックアップの組み合わせで一時的に 5～10Gbps を占有することがあります。QoS を外してから再評価。
  • NIC 直結のセキュリティ製品：エージェント型の DPI/IPS が LSO/RSC で再構成されたパケットを解釈できずにドロップする例があります。検証中は一時無効化で切り分け。
  • vRSS/VMQ の“過剰最適化”：CPU 論理コアよりキューが多い／NUMA を跨ぐ設定は逆効果。まずは VMQ=0, vRSS=Off のシンプル構成が安定の近道。

よくある“ハマり所”と回避策

  • 汎用ドライバーへ巻き戻り：Windows Update 後に “ドライバーが新しくなった” のに不安定化――よく見るケースです。SoftPaq 固定＋更新除外で保守。
  • チーミングの誤用：LBFO チーム上に vSwitch を乗せ、さらに vNIC 側で QoS／VMQ を盛る“三重最適化”は地雷。切り分けは単一 NIC から。
  • レイヤーを跨いだ設定バラバラ：スイッチ側の VLAN／ポートセキュリティ、ホスト側の VLAN タグ、ゲスト側の VLAN 設定が不一致だと断続的に落ちます。まずは VLAN 無しで安定化→段階導入。

検証ログの残し方（再現性の低い障害こそ“記録が命”）

# NIC/スイッチの状態を1ファイルにまとめて保存（定期実行も可）
$now = Get-Date -Format "yyyyMMdd-HHmmss"
$path = "C:\Temp\HyperV-NIC-$now.txt"

"== Host NIC ==" | Out-File $path
Get-NetAdapter | Format-Table -Auto | Out-File $path -Append

"== Advanced Properties ==" | Out-File $path -Append
Get-NetAdapterAdvancedProperty | Sort-Object Name,DisplayName |
Format-Table -Auto | Out-File $path -Append

"== vSwitch ==" | Out-File $path -Append
Get-VMSwitch | Format-List * | Out-File $path -Append

"== VM NIC ==" | Out-File $path -Append
Get-VMNetworkAdapter | Format-List VMName,Name,MacAddress,Status,VmqWeight,VrssEnabled |
Out-File $path -Append

最終チェックリスト（現場投入用）

  • [ ] BCM57416 の ドライバー／ファームを HPE DL380 Gen11 × Server 2022 の適合版に統一した
  • [ ] VMQ / vRSS / LSO / RSC を段階的に無効化し、止まる組み合わせを確認した
  • [ ] 外部 vSwitch を 別ポートで新設し、Sapphire2024 を専用接続で検証した
  • [ ] vNIC を再作成し、静的 MAC を割り当てた（MAC move 警告が消えた）
  • [ ] イベントログに NDIS/NetVsc 系の異常が出ないことを確認した
  • [ ] 即時復旧スクリプトをタスク化し、運用手順書に追記した
  • [ ] SQL バックアップ／メンテ窓と切断の 相関関係を確認した

まとめ（再発を断つための優先度）

根本原因候補は① Broadcom NIC ドライバー／ファームの非整合、② VMQ/vRSS/LSO/RSC などのオフロード機能の相性、③ 物理ポートや vSwitch の競合――の3点に集約できます。したがって、「SPP で NIC を適正化」→「オフロードを段階的に無効化」→「ポート分割で vSwitch を個別化」の順に潰すのが再発防止の定石です。
それでも断続的に再発する場合は、別メーカー NIC へ vSwitch を移設するハードウェア置換検証や、チーミングの完全解除（単一 NIC）によるシンプル構成での耐久観察が、最短で真因に到達する近道です。

付録：Sapphire2024 向けの“最小変更”安定化プリセット（例）

以下は、まず安定化を最優先した暫定プロファイルです。復旧後に必要な機能を個別に戻してください。

# --- ホスト側（pNIC: NIC10G-1） ---
Disable-NetAdapterVmq -Name "NIC10G-1"
Set-NetAdapterRss -Name "NIC10G-1" -Enabled $false
Disable-NetAdapterLso -Name "NIC10G-1"
Disable-NetAdapterRsc -Name "NIC10G-1"

# --- VM側（Sapphire2024 の vNIC） ---

Disable-NetAdapterChecksumOffload -Name "Ethernet"
Disable-NetAdapterLso -Name "Ethernet"

# --- Hyper‑V 設定 ---

Set-VMNetworkAdapter -VMName "Sapphire2024" -VrssEnabled $false
Set-VMNetworkAdapter -VMName "Sapphire2024" -VmqWeight 0
Set-VMNetworkAdapter -VMName "Sapphire2024" -MinimumBandwidthAbsolute 0
Set-VMNetworkAdapter -VMName "Sapphire2024" -StaticMacAddress "00-15-5D-23-45-67"

FAQ（現場でよく出る質問）

Q. DC は安定しているのに、Sapphire2024 だけ切れる理由は？ A. ワークロード（SQL/バックアップ）特性と vNIC/オフロードの相性、あるいは同一 vSwitch 上でのキュー配分が偏っている可能性が高いです。VMQ/vRSS の無効化と vSwitch 専用化で差が縮まることが多いです。 Q. オフロードを切ると性能が下がらない？ A. 理論上は下がりますが、実環境での安定性が優先です。まず安定化し、その後に一つずつ戻して最大帯域ではなく“必要十分な性能”に着地させるのが安全です。 Q. NIC チーミングは使わない方がいい？ A. 切り分け段階では単一 NIC が最善です。恒久対策では SET（Switch Embedded Teaming）を推奨しますが、導入は安定化確認後に。 Q. レガシー ネットワーク アダプターを使えば安定する？ A. Gen1 限定で追加可能ですが、本番の恒久策には適しません。Gen2 では利用不可です。

実施順のテンプレート（コピペ運用可）

  1. SPP/SoftPaq で BCM57416 のドライバー／ファームを適合版へ統一。
  2. pNIC 側で VMQ/RSS/LSO/RSC をすべて無効化 → 48 時間観察。
  3. 止まらなければ vNIC（Sapphire2024）で LSO/Checksum を無効化 → 48 時間観察。
  4. 外部 vSwitch を 2 本目ポートで新設、Sapphire2024 を専用接続 → 72 時間観察。
  5. vNIC 再作成＋静的 MAC 付与、帯域制御解除（Absolute=0）。
  6. イベントログ（NetVsc/NDIS/Tcpip）に異常がないことを確認。
  7. 安定後、必要なオフロード機能を 1 つずつ戻す（戻す度に 24 時間観察）。

結び

“たまに落ちるが再起動で直る” 障害ほど、根本対策が後回しになりがちです。しかし、ドライバー／ファームの適正化とオフロード機能の整理、そして vSwitch のポート分離という三点だけで、実環境は驚くほど静かになります。本記事の手順をテンプレート化し、Sapphire2024 の安定運用に役立ててください。

Hyper-V
PowerShell Hyper-V ネットワークトラブルシューティング Windows Server 2022 Broadcom BCM57416 VMQ LSO

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次