Oracle Cloud VMware Solution（OCVS）は、既存のvSphere運用を活かしたままOracle Cloud Infrastructure（OCI）へ移行できるサービスです。

ただし、OCIコンソールでSDDCを作成すれば移行が終わるわけではありません。本記事では、着手前に固めておきたい設計項目と、仮想マシンの移行までに踏む手順を整理します。

OCVSとは｜OCI上に自社専用のVMware環境をつくるサービス

OCVSは他社のVMwareクラウドサービスと管理範囲の考え方が異なり、その差が設計方針にも影響します。まずはサービスの性格と構成要素、OCIとの関係を押さえておきましょう。

vSphereやvCenterをそのまま使える専有型のクラウド基盤

OCVSは、OCIのベアメタル・インフラストラクチャ上にVMwareベースのSoftware-Defined Data Center（SDDC）を構築するサービスです。ESXiホストは利用企業のテナンシとVCNの内側に置かれ、他社と共有しない専有環境として稼働します。

大きな特徴は、利用企業がSDDCの管理権限を持つ点にあります。オンプレミスと同じ感覚でvCenterを操作できる反面、vSphereやNSX、vSAN、HCXへのパッチ適用は利用企業の責任範囲です。フルマネージド型ではない前提を、検討の初期段階で共有しておきましょう。

ESXi・vCenter・NSX・vSAN・HCXがOCVSを構成する

SDDCの中核は、仮想マシンを動かすESXi、それらを一元管理するvCenter Server、ネットワーク仮想化を担うNSX、複数ホストのストレージを束ねるvSAN、移行を支えるHCXという5つの要素です。

仮想マシンが接続するネットワークは、一般にNSXのオーバーレイセグメントとして設計します。ストレージについては、ローカルNVMeを搭載したシェイプならvSANデータストアを構成でき、それ以外の構成ではOCIのブロック・ボリュームを使います。

OCIのデータベースやロードバランサと組み合わせられる

OCVSはOCIから切り離された別環境ではなく、利用企業のVCN内に配置されます。ルート表やセキュリティ設定を整えれば、コンピュート・インスタンスやDBシステム、Autonomous AI Databaseといった他のOCIリソースと通信できます。

アプリケーションはOCVSに残しつつ、データベースだけをマネージドサービスへ寄せる構成も取れます。まず基盤をクラウドへ移し、その後にシステム単位でOCIネイティブサービスへ移す進め方が現実的でしょう。

出典：Oracle「Overview of Oracle Cloud VMware Solution」

OCVS構築を始める前に確認しておきたいこと

OCVS構築でつまずく原因の多くは、設定作業そのものではなく事前確認の不足にあります。移行方式の妥当性、現行環境の実態、OCI側の制約、ライセンス条件という4つの観点で確認しておきましょう。

OCVSが向いているケースと、他の移行方式が向いているケース

OCVSが力を発揮するのは、アプリケーションの改修が難しく、限られた期間でデータセンター退去やハードウェア更新に対応しなければならない場面です。既存資産を作り替えずに移せるため、移行初期の変化を小さく抑えられます。

一方、仮想マシンが数台程度ならOCI Computeへ個別に移したほうが費用を抑えられます。OCVSはベアメタル・ホストが構成の単位となるため、小規模なワークロードではリソースが余りやすいからです。数年以内にアプリケーション刷新やSaaS移行を予定している場合も、費用の二重負担を含めて比較したほうがよいでしょう。

現行のVMware環境と仮想マシンを棚卸しする

サイジングの精度は、現行環境をどこまで把握できたかで決まります。vCenterやESXiのバージョン、クラスタ構成に加えて、仮想マシンごとの用途や業務重要度、許容停止時間まで洗い出しておきます。

ここで重要なのは、割り当て済みのvCPUやメモリの合計ではなく実際の使用率を測ることです。あわせて移行対象と廃止対象の仕分けも行います。停止したまま放置されたサーバーを持ち込めば、クラウド上で不要なコストを払い続けることになります。

OCIの契約・権限・サービス制限・ベアメタル容量を確認する

OCVSは、OCIのテナンシがあればすぐに使えるとは限りません。設定値が正しくても、テナンシの契約条件が理由でSDDCを作成できなかった事例が技術ブログで報告されています。

出典：APC 技術ブログ「〖OCI〗Oracle Cloud VMware Solution(OCVS)を使おうとして使えなかった話」

技術面では、SDDC数やESXiホスト数、OCPU、VLANなどのサービス制限を確認します。クラスタごとにネットワークリソースが必要になるため、複数クラスタを見込むならサブネットとVLANの計画も欠かせません。

制限に余裕があっても、対象リージョンに必要なベアメタル容量が確保できるとは限りません。稼働日が決まっている案件なら、必要な容量をあらかじめ押さえておくキャパシティ予約の利用も検討に入ります。

VMwareライセンスの扱いはBYOL対応で変わっている

VMwareのライセンス条件は近年動きが大きく、過去の解説記事の前提が現在と一致しない場合があります。2026年3月18日には、OCVSがBroadcomのBYOL（Bring Your Own License）モデルへ対応しました。

出典：Oracle「Oracle Cloud VMware Solution Supports Broadcom's BYOL Model」

このモデルでは、OCPUまたはTiBを基準としたライセンスをBroadcomから直接購入し、OCVS上で登録して割り当てます。vDefend FirewallやAvi Load Balancerといったアドオンも対象です。SDDCの作成画面ではBYOLとライセンス込みのどちらかを選ぶため、見積もり段階で方針を決めておきましょう。

OCVS構築で後から変更しにくい設計のポイント

OCVSには、SDDCを作成した後では修正が難しい設定があります。次の5点は判断を誤ると再構築や追加費用につながるため、構築前の合意形成が欠かせません。

VCNとワークロードのIPアドレスは重複させられない

OCVSのネットワークは、OCI側のVCN、クラスタの管理用CIDR、仮想マシンが接続するワークロードCIDRという3つの層で構成されます。ワークロードCIDRはVCNやクラスタネットワークと重複させられません。

見落としやすいのが、VCNのCIDRを広く取りすぎるケースです。VCNに192.168.0.0/16を割り当てると、同じ範囲をNSXのワークロードネットワークへ使えなくなります。安全のつもりで広く確保する判断が、かえって制約を生むわけです。

管理用CIDRのサイズは、作成できるノード数に直結します。公式ドキュメントでは、/24で3〜12ノード、/23で3〜28ノード、/22で3〜60ノード、/21で3〜64ノードと示されています。初期台数ではなく将来の最大構成を基準に決めましょう。

出典：Oracle「Creating a VMware Solution SDDC」

DenseシェイプとStandardシェイプ、ホスト台数の決め方

ESXiホストのシェイプは、ストレージの持たせ方で性格が分かれます。DenseシェイプはローカルNVMeでvSANを構成でき、1クラスタあたり最大64ホストまで拡張できます。Standardシェイプはブロック・ボリュームを使うため低コストな選択肢になりますが、上限は32ホストで、SDDCの作成前にデータストアクラスタを用意しておく必要があります。

台数は、本番環境なら3ホスト以上のマルチホスト構成が前提です。単一ホストSDDCは検証や短期開発には有効なものの、HAが働かずSLAの対象にもならず、バックアップも取得されません。マルチクラスタ構成へそのまま拡張できない点にも注意が必要です。

料金コミットメントとHCXの選択はやり直しが効かない

OCVSの料金は、時間単位、月単位、1年、3年といった間隔から選びます。ホスト単位で後から変更できるものの、新しい間隔が適用されるのは現行期間が終わってからです。途中で解約しても、期間が満了するまで請求は続きます。

検証用ホストを長期契約で作成してしまう事故を防ぐには、作成前に見積書と設定値を突き合わせ、申請者と承認者を分けて確認する運用が有効でしょう。

HCXの扱いはさらに厳格で、SDDC作成時に有効化しなければ後からプラグインを追加できません。使う可能性が少しでもあるなら、有効化しておく判断が現実的です。有効にする場合は、選択するVCNにNATゲートウェイが必要になる点も押さえておきます。

出典：Oracle「VMware Solution Billing Options」

オンプレミスとの接続はFastConnectかVPNかを決める

オンプレミスとOCIをつなぐ手段は、専用線を利用するFastConnectと、インターネット経由のSite-to-Site VPNに大別されます。サイト間の通信にはFastConnectが推奨されており、大量のデータを移す場合や長期のハイブリッド運用では有力な選択肢になります。

必要な帯域は理論値だけで判断しないことが大切です。50TBのデータを10Gbpsの回線で移すとしても、実効速度が常に上限へ達するわけではありません。移行リハーサルで転送速度を実測しておくと、計画の精度が上がります。

なお、オンプレミスとVCNの接続は、SDDCをプロビジョニングする前に整えておくことが推奨されています。回線の手配には時間がかかるため、早めに着手したい工程です。

バックアップと運用の責任範囲は構築前に決めておく

OCVSは、利用者と提供者で責任を分担するモデルで運用されます。Oracleが担うのは物理インフラの保護であり、SDDC内部の設定やデータの保護は利用企業側の作業です。移行後にバックアップ設計を始めると、切替直後の障害に対応できない期間が生まれます。

対象は業務用の仮想マシンだけではありません。vCenterやNSXの構成情報、証明書や暗号鍵まで含めて保護対象を定義します。パッチ適用の計画も利用企業側で管理するため、責任分界を文書化し、運用パートナーとの分担を明確にしておきましょう。

出典：Oracle「Securing VMware Solution」

SDDCの作成から仮想マシンの移行までの実践手順

設計が固まったら構築作業に入ります。SDDCの作成そのものは比較的短時間で終わりますが、その後の初期設定と移行環境の準備には相応の工数がかかると見ておきましょう。

SDDCを作成し、パスワードや証明書の初期設定を行う

作成はOCIコンソールのSDDC一覧ページから開始します。入力するのはSDDC名、コンパートメント、VMwareソフトウェアバージョン、SSH公開鍵、ライセンスモデル、HCXの有無、そして管理クラスタの構成です。画面上の項目の並び順は変わる場合があるため、名称を追うのではなく設定の意味を理解したうえで進めてください。

プロビジョニングが完了すると、詳細画面にvCenterへアクセスするためのユーザー名と初期パスワードが表示されます。ここで示されるパスワードは変更後も表示が更新されないため、認証情報は自社の管理台帳で扱う前提に切り替えます。あわせて証明書の入れ替えとActive Directory連携を進め、パスワードのローテーション手順も決めておきます。

HCXでオンプレミスとOCVSをつなぐ

SDDC作成時にHCXを有効化していれば、OCVS側のHCX ManagerはvCenterと統合された状態で用意されます。作業の中心になるのは、むしろオンプレミス側の準備です。

オンプレミスにはHCX Connectorを展開し、ライセンス登録とvCenter連携を済ませてからサイトペアリングを行います。続いてNetwork ProfileとCompute Profileを作成してService Meshを構成すると、移行に使うアプライアンスが両サイトへ展開されます。

L2ネットワークを延伸すれば移行の前後でIPアドレスを保てますが、恒久的な利用は経路を複雑にします。解除の時期まで含めて計画しておきましょう。

移行方式はシステムの重要度に応じて使い分ける

移行方式を1つに統一する必要はありません。停止時間を最小化したい重要な仮想マシンにはHCX vMotion、多数の仮想マシンをまとめて移すウェーブにはBulk Migrationというように、対象ごとに選び分けるほうが合理的です。

大規模な移行と短い停止時間を両立させたい場合は、レプリケーションとvMotionを組み合わせたReplication Assisted vMotionが候補になります。停止時間を確保できる開発環境ならCold Migrationで足り、HCXの要件を満たさない仮想マシンにはVeeamやZertoを用いる方法もあります。

パイロット移行で切替手順とロールバック条件を確かめる

本番システムに着手する前に、必ずパイロット移行を実施します。対象には、業務影響が限定的でありながら、データベース接続や認証連携といった要素を含む仮想マシンを選ぶと検証の密度が上がります。

このとき作成するのが時系列の切替手順書です。バッチ停止から最終同期、移行先での起動、疎通確認、利用者への開放までを並べ、担当者と判断基準を割り当てます。ロールバックの条件も、所定時間内に起動しない、性能が基準値を下回るといった形で数値化しておきます。

移行後もオンプレミス側の仮想マシンはすぐに削除せず、電源を落とした状態で一定期間は保管します。問題が起きたときに元へ戻せる状態を残しておくためです。

ここまで見てきたように、移行方式の選定や切替リハーサルは経験がものを言う工程です。自社だけで進めることに不安があれば、外部の支援を組み合わせる方法もあります。たとえばクロスキャットのOCVS構築支援サービスでは、基盤構築に加えて移行ツールの設定から本番切替、設計書や手順書の作成までを支援しています。

まとめ｜OCVS構築の成否は事前の設計と体制で決まる

OCVSは、既存のVMware資産を大きく作り替えずにOCIへ移行できる有力な選択肢です。ただしSDDCを作成する操作は工程全体の中盤に位置しており、成否を分けるのは前段にある調査と設計の品質だと言えます。

本記事で解説した内容のうち、特に押さえておきたい要点は次のとおりです。

• パッチ適用やデータの保護は利用企業の責任範囲であり、フルマネージド型ではない
• 現行環境は割当量ではなく実使用率で把握し、移行対象と廃止対象を仕分ける
• VCN、クラスタ管理、ワークロードのIPアドレスは重複させられない
• 料金コミットメントは、解約しても選択した期間が終わるまで請求が続く
• HCXはSDDCの作成時に有効化しなければ、後から追加できない
• パイロット移行でロールバック条件まで検証してから本番切替へ進む

なかでも、IPアドレスの重複、サービス制限、ベアメタル容量、HCXの初期選択、料金コミットメントの5点は、後から修正しようとすると再構築や追加費用を伴います。

OCIとVMwareの双方に知見が求められる領域です。要件定義から基盤構築、移行、バックアップやDRの設計まで一貫して支援できる体制を整えられるかが、プロジェクト全体の成否を左右します。社内リソースだけで進めることに不安があれば、早い段階で外部の知見を取り入れる選択も検討してみてください。