Windows Admin Centerのクラスター作成で「Remove Existing Switches」が出る原因と対処｜Hyper-V仮想スイッチを消すべきか

Windows Admin Center（WAC）でクラスター作成を進めると「Remove Existing Switches（既存スイッチを削除）」が表示され、YES/NOで迷うことがあります。すでにHyper-Vの仮想スイッチ（vSwitch）がある構成では、選択を誤るとVMの通信断や管理接続断につながることも。本記事では表示される理由、YES/NOの影響、2台・各2NIC構成での安全な進め方を具体的にまとめます。

結論：既存のHyper-V仮想スイッチを維持したいなら「NO」

先に結論から整理します。今回のようにNIC1にすでにVM用のHyper-V仮想スイッチが存在し、その構成を壊したくない場合は、基本的に「NO」が安全です。

NO：既存のvSwitchを残したままウィザードを進める（既存VMネットワークを維持しやすい）
YES：既存のvSwitchを削除する方向に進む（VM通信・紐づけ・管理IPに影響が出やすい）

「YES」を選ぶのが合理的なのは、新規構築で“まっさらに組み直す”前提、またはVMを退避済みでネットワークを作り直しても問題ない場合に限る、と考えると判断がブレません。

「Remove Existing Switches」とは何を消すのか

WACのクラスター作成ウィザードが表示する「Remove Existing Switches」は、主にHyper-Vの外部仮想スイッチ（External vSwitch）など、物理NICに紐づいている“既存のスイッチ構成”を指します。

なぜこの確認が出るかというと、クラスター作成の流れの中でWACがネットワーク構成（どのNICをどの用途に使うか、スイッチを作るか等）を一定の“型”に揃えようとする場面があり、既に別のvSwitchがぶら下がっているNICだと、ウィザードが想定する構成に変更できないからです。

特に次のような状況で表示されやすくなります。

選択した物理NICが、すでにHyper-V仮想スイッチに紐づいている
既存vSwitchの上に管理OSのvNIC（vEthernet）が存在し、OSの管理IPがそこに載っている
ウィザードが“新しくスイッチを作る/作り直す”前提で進行しようとしている

要するに、このメッセージは「そのNICはすでにvSwitchで使われているけど、こちらで作り直す？既存を消して良い？」という確認に近いものです。

YES/NOの影響を一枚で整理（最重要）

クリック前に、影響範囲を機械的に把握できるようにまとめます。

選択	WAC側の挙動イメージ	起こり得る影響（弊害）	向いている状況
NO	既存vSwitchを削除せず、残した状態で後続ステップへ	既存VMネットワークを維持しやすいただし、ウィザード上で“vSwitchを作成する対象NIC”の選び方を誤ると進行しづらい場合がある	NIC1のVM用vSwitchを維持したい稼働中VMがいる、もしくは設定を壊したくないクラスター通信を別NIC（NIC2）へ寄せたい
YES	既存vSwitchを削除し、WACの想定に合わせて作り直す方向へ	VM通信断（VMが接続している仮想スイッチが消える）管理接続断（管理IPがvEthernetに載っている場合、IPや経路が崩れて遠隔操作が切れることがある） vLAN設定、QoS、NIC詳細設定などの“積み上げ”が消える/戻る可能性	新規構築で、VMはまだ載せていない VMを別ホストへ退避済みで作り直し前提ローカルコンソール（iLO/iDRAC等）で復旧できる体制がある

特に注意したいのは、「YES＝消して良いスイッチだけを上品に消す」ではない点です。実態としては、スイッチに紐づく設定が広く崩れる可能性があるため、YESは“ネットワーク作り直し”の覚悟がある時だけ選ぶ、が安全運用の鉄則です。

2台・各2NIC構成での現実的な設計例（NIC1にVM用vSwitchあり / NIC2でクラスター通信）

2NIC構成は“できなくはないが、設計の自由度が低い”のが本質です。だからこそ、最初に「どの通信をどこへ流すか」を決め打ちしておくと、WACのウィザードでも迷いが減ります。

今回の前提（NIC1にVM用vSwitchがすでにある、クラスター通信はNIC2へ）に寄せた一例です。

物理NIC	主な役割	設定のポイント	よくある落とし穴
NIC1	VM通信（既存vSwitch）（場合によりホスト管理もvSwitch経由）	既存vSwitchは維持（Remove Existing SwitchesはNO）管理OSのvNIC（vEthernet）を使って管理IPを持たせる構成なら、IP/ゲートウェイがどこに載っているか確認 VM用VLANがあるなら、VM側のVLAN設定を記録しておく	管理IPがvSwitch側にあり、YESでスイッチ削除すると遠隔管理が切れる物理NICにIPが残っていないケースが多く、復旧にコンソールが必要になりがち
NIC2	クラスター通信（ハートビート） Live Migration CSV/クラスタ内部通信（設計による）	ホスト間で疎通できる同一セグメントを用意（例：10.x.x.x/24等）専用ネットワークならデフォルトゲートウェイは設定しないのが基本（ルーティング混乱を避ける） DNS登録はオフにすることが多い（環境ポリシー次第）	ゲートウェイを入れてしまい通信経路が逆転、名前解決や管理通信が不安定 Live Migrationを流し過ぎてクラスター通信と競合（特に1GbE）

2NIC構成で「VMもクラスターも高速で、切り分けも簡単に」は難しいため、実運用では“NIC2はクラスター寄り（ハートビート/Live Migration/内部）に固定して、NIC1はVM寄りに固定”のように割り切るとトラブルが減ります。

「NO」を選んで安全に進める手順（既存vSwitch維持ルート）

ここが最も需要のある手順です。ポイントは「既存vSwitchの乗っているNICを、ウィザードが作り直し対象として扱わない」ことです。

事前チェック（クリック前にやること）

最低限、次を確認してからウィザードを進めると事故率が激減します。

チェック項目	目的	確認の目安
既存vSwitchがどの物理NICに紐づいているか	削除対象になっていないか把握	NIC1に外部vSwitchが紐づいているのを確認
管理IPが物理NICか vEthernet か	YES選択時の遠隔切断リスク評価	管理IPがvEthernet側なら、スイッチ削除で切断しやすい
NIC2にクラスター用のIP設計があるか	クラスター作成/検証で躓かない	ホスト間疎通できる同一セグメント、基本はGWなし
管理用NIC（iLO/iDRAC等）がOSに見えていないか	誤認・誤設定の回避	WACのNIC検証に出てくるなら除外候補

WACウィザードで意識するポイント

Remove Existing Switchesは「NO」を選ぶ
NICの選択画面が出たら、既存vSwitchがぶら下がるNIC1を“新規にスイッチを作る対象”に入れない（入れると結局作り直しを求められる）
クラスター通信に使いたいNIC2だけを、ウィザード上でクラスター用途として扱うように寄せる
「Verify NIC adapters（NICアダプターの検証）」などで、iLO/iDRAC/USB NICが候補に出てきたら外す

WACの画面構成は環境や拡張機能で多少変わりますが、考え方は同じです。“すでに運用中のVMネットワーク（NIC1）を、ウィザードの自動化に触らせない”が核心です。

クラスター作成後に必ず見直したい項目

クラスター作成が完了しても、ネットワークの役割が意図通りになっていないことがあります。後工程で次を見直すのが実戦的です。

Live Migrationの優先ネットワーク（NIC2を優先させたいなら設定）
クラスター内部通信（ハートビート）のネットワーク優先順位
CSVリダイレクトが発生した時の経路（帯域不足だと性能劣化が顕在化）

2NIC構成では特に、Live Migrationが走った時にクラスター通信まで圧迫しがちです。移行を多用する運用なら、Live Migrationに帯域制御（QoS）を入れる、移行タイミングを制御する、といった“運用で守る”設計も検討すると安定します。

「YES」を選ぶ場合の前提条件（作り直し前提ルート）

YESが悪ではありません。ただし、YESを選ぶなら次の前提を揃えてからにしてください。

対象ホスト上のVMがいない、または別ホストへ退避済み
ネットワーク断が起きても復旧できるよう、ローカルコンソール（iLO/iDRAC等）に入れる
現在の設定（vSwitch名、VLAN、VM接続、管理IPなど）を控えてある

特に重要なのは「コンソールがあるか」です。遠隔操作だけで作業していると、YESの直後に管理経路が切れて詰むことがあります。

YESを押す前に“必ずメモ”しておきたい情報

メモする項目	理由	例
vSwitch名	VM側設定の復旧が早い	vSwitch-VM / ExternalSwitch など
どの物理NICに紐づいているか	作り直し時に迷わない	NIC1（Intel X710 Port1）など
管理IPの所在（物理NIC or vEthernet）	切断リスクを見積もる	vEthernet(Management)に静的IP
VMの接続先スイッチとVLAN	通信断復旧を最短化	VM1→vSwitch-VM VLAN 120

作り直し後にやること

YESで作り直したら、最後に次の確認まで終えてからVMを戻すのがおすすめです。

ホスト間の疎通（管理系・クラスター系）
VMスイッチ経由の通信（VMのゲートウェイ疎通）
Live Migrationテスト（小さなVMで1往復）

補足：iLO/iDRACなど管理NICはクラスターNICの検証対象から外す

HP iLO、Dell iDRAC、Lenovo XClarityなどの管理機構は、“OSとは別系統で管理する”ためのNICです。ところが環境によっては、OS側にUSB NICのような形で見えてしまい、WACの「Verify NIC adapters（NICアダプターの検証）」に候補として並ぶことがあります。

これをクラスター作成の対象に入れてしまうと、次のような事故につながりやすくなります。

WACが“使えるNIC”と誤認し、検証や構成でつまずく
意図しないNICにクラスター通信が割り当たる（または割り当てようとして失敗する）
管理NICは帯域・機能が特殊で、クラスタ要件（仮想化/スイッチ/SMB等）に合わない

対策はシンプルです。

WAC上のNIC選択でチェックを外す
OSから見えてしまう管理NICは、必要に応じて無効化しておく（クラスター構築作業中だけでも可）

ここは“ハマりどころ”として非常に多いので、最初に外しておくのが結果的に最短ルートです。

もし誤って「YES」を押してネットワークが崩れた時の復旧方針

万一、YESを押して既存vSwitchが消え、ホストやVMの通信が途切れた場合は、慌てず次の順序で戻すと復旧しやすいです。

復旧の優先順位

ホストの管理経路を復活（RDP/WinRM/WACに入れる状態に戻す）
vSwitchを再作成（必要なら管理OSの共有も戻す）
VMをスイッチに再接続し、VLAN等を戻す
クラスター関連（Live Migration等）を調整

遠隔が切れてしまった場合は、iLO/iDRACなどのリモートコンソール、または現地KVMでログインして対応します。

vSwitch再作成の考え方（例）

構成は環境依存ですが、基本は「外部仮想スイッチを作る → 管理OSの共有（必要なら） → IPを戻す → VMを接続」です。PowerShellで状況把握するなら、次のようなコマンドが役に立ちます。

Get-NetAdapter | Sort-Object Status, Name
Get-VMSwitch
Get-VMNetworkAdapter -ManagementOS

スイッチが消えているなら、まずはホストが管理できる状態を取り戻した上で、必要なスイッチを作り直し、VMを繋ぎ直します。復旧時は“急いで全部戻す”より“管理→スイッチ→VM”の順で確実に進める方が結果的に早いです。

運用の勘どころ：役割分離はNIC本数が正義（最低2本でも組めるが…）

今回のような2NIC構成は、どうしても複数の役割が同じ線を共有しがちです。そこを運用でカバーするには、設計段階で“どこがボトルネックになり得るか”を把握しておくことが重要です。

NIC本数	設計のしやすさ	役割分離の例	コメント
2本	難しい	NIC1：VM / 管理（vSwitch） NIC2：クラスター / Live Migration	移行やバックアップが重なると競合しやすい。運用ルールと監視が重要。
3本	現実的	NIC1：VM（vSwitch） NIC2：クラスター内部 NIC3：Live Migration	移行を分離できるだけで体感安定度が上がる。
4本以上	楽	管理 / VM / Live Migration / ストレージ（iSCSI等）を分離	トラブルシュートが圧倒的に簡単。性能設計も立てやすい。

もちろん、10GbE以上のNICを使い、VLANやQoSで論理分離して“少ない本数で回す”設計もあります。ただ、構築担当と運用担当が同じでない現場ほど、物理分離のメリットが大きいのも事実です。将来の拡張（VM増加、Live Migration増、バックアップ増）を見越すなら、可能な範囲でNIC増設を検討すると後悔しにくくなります。

確認・切り分けに使えるコマンド集（覚えておくと強い）

WACの画面だけだと原因が見えづらいときがあります。現場でよく使う確認コマンドをまとめます。

vSwitchと物理NICの紐づき確認

Get-VMSwitch | Format-Table Name, SwitchType, NetAdapterInterfaceDescription -Auto

管理OS側のvNIC確認（管理IPがどこに載っているか）

Get-VMNetworkAdapter -ManagementOS | Format-Table Name, SwitchName, MacAddress -Auto
ipconfig /all

NICの状態・リンク速度の確認

Get-NetAdapter | Format-Table Name, Status, LinkSpeed, MacAddress -Auto

クラスター作成後のネットワーク状況確認（作成後に有効）

Get-ClusterNetwork | Format-Table Name, Address, AddressMask, Role, Metric -Auto

「Remove Existing Switches」で迷う状況は、結局のところ“どの物理NICが、何に使われているか”を把握できていないと判断が難しくなります。上のコマンドで実態を掴むだけでも、選択ミスはかなり減ります。

まとめ：迷ったら“既存VMネットワークを壊さない”判断を優先する

Windows Admin Centerのクラスター作成で「Remove Existing Switches」が出たときは、メッセージの強さに引っ張られてYESを押しがちですが、既存のHyper-V仮想スイッチを維持したいならNOが基本です。

稼働中のVMや既存ネットワークを守りたい → NO
新規構築で作り直し前提、退避・復旧手段あり → YES
iLOなど管理NICが候補に出る場合は、必ず除外

2台・各2NIC構成でもクラスターは組めますが、役割が競合しやすい分、最初の設計と“触ってはいけない部分を触らせない”運用が重要になります。WACの自動化は便利な一方で、既存構成がある環境では「残すもの」と「任せるもの」を切り分けるのが成功のコツです。

この記事を書いた人

佐藤健司

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