Google CloudでVMwareを自社管理する形 VCF 9を持ち込み、更新も自社で

Google Cloudで、VMwareのパッチを自社で当てる形が選べるようになりました。手持ちのVMware Cloud Foundation（VCF）のサブスクリプションを持ち込み、ESXiからNSXまで管理者の権限で触れます。その代わり、ソフトの更新も、障害の窓口の切り分けも自社の仕事です。

Google Cloudは2026年10月27日（米国時間）、「VMware solution on Google Cloud」の一般提供を始めました。専用のベアメタルのサーバーにVCF 9.xを利用者が入れて使う形で、9月から一部の顧客に試験提供していたものです。Googleが運用まで引き受けるGoogle Cloud VMware Engine（GCVE）と並ぶ、2つ目の選び方になります。

Googleに任せるか、自社で持つか

2つの形の違いは、どこまでを利用者が触るかにあります。GCVEでは、パッチや更新、監視をGoogleが自動で行い、利用者に渡るのはvCenterの役割ごとの管理者権限です。新しい形では、ESXi、vCenter、NSX Managerを含むVCF全体にrootで入れます。更新は利用者か、委託したパートナーが行います。

ただ、ライセンスの扱いは資料によって書き方が違います。ブログの表と料金のページでは、GCVEも「ポータブルのVCFのライセンスが必要」です。ところが、2つの形を比べる文書では、GCVEのライセンスは「込み」のまま。GCVEを候補に入れるなら、どちらの契約になるのかを見積もりの段階で確認しておくのが安全でしょう。

ノードは1種類だけです。CPUは96コア（192 vCPU）、メモリーは1.5TB、NVMeのSSDは約72TBで、ネットワークは200Gbps。高可用性の構成には、1つのクラスターに4台以上が要ります。Google Cloudの確約利用割引をこのベアメタルの費用に充てられる点は、Googleがコストの面で強調しているところです。

パッチも、障害の問い合わせ先も自社で決める

責任共有モデルの文書を読むと、Googleの受け持ちはハイパーバイザーの手前までです。データセンター、サーバーの機材、ネットワークの基盤、ホストの保守はGoogleが受け持ちます。VCFのライセンスの調達と、vCenterやSDDC Manager、vSAN、NSXの導入、パッチと更新、アップグレードは利用者の側。GoogleはVCFのパスワードや設定を見られないため、認証やアクセス権、証明書も利用者が設定します。

運用で気をつけたい点は3つあります。

• ホストの保守の前に、利用者がESXiを保守モードにする。Googleはホストの保守が要るとき、期限を付けて知らせ、期限を過ぎると自動で保守を始めます。それまでに、VCFの側で仮想マシンを逃がしておく手順が要ります。
• 上げてよいESXiの版は、Googleの検証が済んだものだけ。GoogleはBroadcomが出したESXiの新しい版を自社の機材で検証し、終わるとリリースノートで知らせます。Broadcomが急ぎの修正を出しても、すぐには当てられない場面がありそうです。
• ノードを止めると、ローカルのSSDのデータは消える。止めて再開したときも、削除したときも同じです。vSANの冗長性を保ったまま、先にデータを移しておきます。

問い合わせ先も2つに分かれます。機材とGoogleのネットワーク、Googleが検証したESXiのイメージは、GoogleのCloud Customer Careです。VCFのソフト、vSphere、vSAN、NSX、ライセンスの質問はBroadcomのサポートに出し、持ち込んだサブスクリプションの権利を使います。原因がどちらにあるか分からないときは、どちらに出してもかまいません。両社が連携して切り分けるとGoogleは説明しています。

社内で回せないなら、運用ごと外に出す道もあります。Googleは設計から移行、運用までを請け負うパートナーとして、Accenture、IBM、Tata Consultancy Servicesなど15社を挙げました。

東京は1ゾーンだけ、大阪にはない

提供は22のリージョンからと発表されましたが、ブログにも文書にもリージョンの一覧はありません。手がかりは、Compute Engineのベアメタルの提供場所の表です。このサービスが使うz3-highmem-192-highlssd-metalは、東京ではasia-northeast1-bの1ゾーンにだけ載り、大阪の3つのゾーンにはありません（10月28日確認）。

東京と大阪に1つずつVMwareの環境を置いて災害対策を組む使い方は、今の表の上では組めないことになります。1つのゾーンの中で、ノードを別々のラックや電源に分ける配置の設定は使えます。台数を多く使う場合は、割り当て（クォータ）があっても機材の空きは保証されないため、前もって営業と調整するよう文書は勧めています。Googleの移行支援の製品群でも、東京に来ていない機能があることは、Google Cloud Modernizeとは 新しい点と料金・データの扱いで書きました。

GCVEの中身はVCF 5.2のまま

比較の表で、もう一つ目を引くのが版です。GCVEは今もVCF 5.2で動いています。Broadcomは、vSphere 8と同じ2027年10月11日に、VCF 5.2.xの一般サポートも終えるとしています。対象の製品と日付は、vSphere 8は2027年10月11日にサポート終了 残るか移るかの判断材料にまとめました。今回の発表は、GCVEをいつVCF 9に上げるかには触れていません。

GCVEは更新をGoogleが受け持つので、版を上げる作業そのものは利用者の手を離れています。気になるのは、その時期と、上げる間に仮想マシンがどう止まるかです。GCVEへの移行を考えている会社は、2027年10月より前に9.xへ移る予定を、契約の前に聞いておきたいところです。

影響を受けるのは、VMwareをGoogle Cloudへ移す計画がある会社

• 影響を受ける: データセンターの退去やサーバーの更新に合わせて、社内のVMware環境をGoogle Cloudへ移す計画がある会社。GCVEのほかに、自社で管理する形も比べられます。
• 影響を受ける: VCFのサブスクリプションを持ち、クラウドへ持ち込める権利がある会社。新しい形では、その契約のまま使えます。
• 影響を受ける: GCVEを使っている、または契約を考えている会社。VCF 5.2と、2027年10月11日のサポート終了の関係を確かめます。
• 影響しない: VMwareを使っていない会社や、ほかのクラウドかオンプレミスで続けると決めている会社。

見積もりの前に確認すること

まず、手持ちのVCFの契約が、クラウドへ持ち込めるポータブルの権利を含むかを、Broadcomの契約書かサポートポータルで見ます。新しい形はこれが前提です。

次に、自社で回せるかを決めます。ESXiのパッチの適用、Googleの保守の知らせへの対応、Broadcomへの問い合わせを、誰が受け持つか。今のオンプレミスで情シスが担っている仕事が、そのままクラウドの上でも続くと考えて数えるのが近いでしょう。手が足りなければ、パートナーの運用代行を見積もりに入れます。

置き場所も照らし合わせます。東京は1ゾーンだけで大阪には無いため、災害対策の構成や、データを国内に置く社内の決まりと合うかを確認します。

最後に、GCVEと比べるなら、ライセンスの扱いとVCF 9への移行の予定を、書面で受け取っておきます。vSphere 8のサポート終了まで、残りは1年を切りました。選択肢が増えたこと自体はよい知らせですが、新しい形は「パッチを自分で当てる」約束と引き換えです。