Skip to content

仮想マシンと移行

データセンターに仮想ネットワークが構成されると、その論理スイッチは VM を接続できるネットワークとなり、移行時に必要な処理が変化します(主に作業を減らす方向で)。


VM を論理スイッチにアタッチする

VM ウィザードおよび VM の NIC 設定において、ブリッジや libvirt ネットワークと並んで OVN 論理スイッチがネットワークタイプとして選択できます。スイッチを選択すると、Cockpit はその指定を Vapor に渡します。

ユーザーが手動で行う必要のない 2 つのこと:

  • ポートの名前付け。 Vapor が論理スイッチポートを作成し、libvirt が要求する名前(UUID)を付与します。Cockpit が勝手に名前を作ることはありません。
  • アドレスの選択。 スイッチで DHCP が有効な場合、Vapor はそのポートにインターフェースの MAC アドレスを固定(ピン留め)し、OVN の DHCP がゲストに応答できるようにします。この固定こそが DHCP を機能させる鍵です。これがないと OVN と libvirt が別々の MAC を選んでしまい、ゲストがリースを取得できなくなります。

その後、VM のネットワークには VM がどこで稼働していても論理スイッチ名が表示されます。Cockpit はホストの同期からこの接続情報を学習するため、VM 作成後まもなくインベントリに反映されます。

Kubernetes プロビジョナー

プロビジョナーは分散ネットワークと並んで論理スイッチを候補として提示します。すべてのノードのホストがそのネットワーク上に存在するという同じ理由で両者とも適合するため、ノードが異なるホストに配置されたクラスターや、データセンター内の異なるクラスターであっても、単一のネットワークを持つことができます。


同一デプロイメント内での移行

論理スイッチは、デプロイメント内のすべてのシャーシ上で同一のスイッチです。そのため、論理スイッチ上の VM は、手動移行、DRS、HA 再起動、ホスト退避など、いかなる方法・方向であってもネットワークマッピングを必要としません。移行ウィザードはインターフェースを認識し、分散ネットワークの場合と同様にマッピング不要として処理を進めます。

ライブ移行も完全にサポートされています。VM の論理ポートは宛先シャーシにリバインドされるだけであり、IP アドレスなどの設定は何も変わりません。

これは分散ネットワークよりも強力です。その理由を理解することは有益です。分散ネットワークは、たまたま一致しているホストごとの設定であり、2 台のホストで同じ名前のネットワークがあることは Cockpit がチェックしなければならない偶然の一致に過ぎません。これに対し、論理スイッチは単一のオブジェクトであり、チェックすべき不一致自体が存在しません。


異なるデプロイメント間での移行

2 つのデータセンターにはそれぞれ独立した 2 つのファブリックが存在し、一方の論理スイッチは他方の同名スイッチとは別物です(両者の間にレイヤー 2 はなく、トンネルも接続されていません)。その境界を越える VM はネットワークを変更することになるため、移行ウィザードはその前提で処理します。

コールド移行のみ対応

デプロイメント間のライブ移行は拒否されます(Cockpit および Vapor の双方によって)。ゲストの MAC と IP が異なるブロードキャストドメインに突如再出現し、すべての上流キャッシュが古いままになるため、ライブ移行が「成功」したとしても NIC が通信不能な稼働中 VM が残るだけになります。事前に VM をシャットダウンしてください。ウィザードはその旨を通知し、ライブオプションを無効化します。

インターフェースのマッピング

論理スイッチ上の各インターフェースについて、ウィザードは移行先をどこにするかを尋ねます。移行先ターゲットには 3 つの種類があります。

ターゲット動作
移行先デプロイメントの論理スイッチそのスイッチ上に新しいポートが作成され、VM の MAC が固定され、インターフェースがそこに接続し直されます。移行先に同名のスイッチが存在する場合、ウィザードはそれを提案します(2 つのデータセンターが同じネットワーク計画を持つミラーファブリック構成の場合)。
移行先ホストのブリッジインターフェースは OVN インターフェースではなくなり、通常のブリッジ接続 NIC と同様にブリッジにアタッチされます。
移行先ホストの libvirt ネットワーク同様に、libvirt ネットワークにアタッチされます。

逆のパターン(ブリッジや libvirt ネットワークのインターフェースを論理スイッチにマッピングする場合)も同様に動作します。

IP アドレスの扱い

MAC アドレスは常に維持されます。IP アドレスは条件付きであり、移行後にゲスト側で判明するのを待つのではなく、ウィザードが移行前に各インターフェースの判定結果を明示します。

  • Preserved(維持される) — ターゲットが、VM の現在のアドレスを含むサブネットを持つ論理スイッチである場合。新しいポートにアドレスが固定されるため、ゲストの DHCP リースは一致し続けます。
  • Will change(変更される) — ターゲットスイッチのサブネットが異なる場合。ゲストはそのサブネットの DHCP から新しいアドレスを取得するか、静的 IP の場合は手動で再設定する必要があります。
  • Not applicable(該当なし) — ターゲットがブリッジまたは libvirt ネットワークである場合。OVN は DHCP に応答しなくなり、そのネットワークを提供する側の仕組みが担当します。

ポートはリークせず適切にクリーンアップされる

移行元スイッチ上のポートは、移行先で VM が正しく定義された後にのみ、かつ実際に別のネットワークへ移動したインターフェースについてのみ削除されます。移行先での定義に失敗した場合は新しいポートが削除され、移行元はまったく元のまま維持されるため、VM は元の場所で動作し続けます。


退避と高可用性 (HA)

ホスト退避と HA 再起動も同じルールに従います: 同一デプロイメント内であれば論理スイッチはマッピング不要であり、VM は自身のネットワーク上で再起動します。これらがデプロイメントを越えて VM を自動移動させることは決してなく、デプロイメントをまたぐ移動は常に明示的な移行操作となります。


関連トピック