Red Hat OpenShift Virtualizationへの仮想マシン高速移行の鍵は実はストレージ？
本記事はRed Hatとしての公式見解ではなく、筆者個人のブログです。言及する各社製品・機能の情報は執筆時点の筆者の理解によるもので、採用検討時は各社の公式情報を確認してください。
この分野は変化が速いテーマです。公式見解を待つより、今分かっている情報を先に共有する方が読者の役に立つと考え、個人として発信しています。
この記事の目的
仮想基盤をOpenShiftへ移行する方法として、Red HatではMTV(Migration Toolkit for Virtualization) という機能を用意しています。
MTVでの仮想マシン移行には、いくつかのパターンが存在します。
特にVMware環境からの移行方式としてよく話題に上がるのが VDDK(Virtual Disk Development Kit) を用いた高速仮想マシン移行です。しかし、MTV利用下での高速化移行手段はVDDKだけではありません。
本記事では、2026年9月時点で存在するもう1つの移行手法である ストレージコピーオフロード(Storage Copy Offload) を用いた方法について、ストレージの専門家ではない方にも分かるように解説します。
VDDK自体の内部実装や、VDDKの入手を巡る背景・是非には触れません。あくまで「ストレージコピーオフロードという選択肢」にフォーカスします。
結論（先出し）
まず前提として、Red Hat MTVでは仮想マシンの移行パターンに以下の2種類が存在します。
| 観点 | (1)ネットワーク経由 | (2)ストレージコピーオフロード |
|---|---|---|
| 仮想マシンデータの転送経路 | ネットワーク | ストレージ筐体内で完結 |
| VDDKの要否 | 利用は任意だが、利用すると高速 | 不要 |
| 移行速度 | ネットワーク帯域などに依存 | ストレージ内で完結するため高速 |
| 条件 | 特になし | 対応するストレージ機器が必要 |
| ネットワーク負荷 | データ量に応じて発生 | 大幅に軽減 |
ストレージコピーオフロード機能に対応するストレージ製品があれば、VDDKが無くても、むしろVDDK以上に高速な移行手段があります。
※このメリットは、移行元・移行先が同一のストレージ機器である場合に限られます（詳細は後述）。
Q. そもそも「オフロード」とは何か
A. ある処理を、他の誰か（何か）に肩代わりしてもらうことです。
ストレージの世界で言えば、「データのコピーという力仕事を、サーバーではなくストレージ機器自身にやらせる」ことを指します。普段は、サーバーが「ストレージからデータを読む→サーバーの中を経由する→また別の場所へ書き込む」という作業をしていますが、これをストレージ機器に直接任せてしまうイメージです。
これにより、次のようなメリットが生まれます。
- サーバー側の負荷が減る
- サーバーとストレージの間のネットワークにデータが流れないため、ネットワークも混雑しない
- 結果として、速くて周りにも優しい処理になる
このような「コピーの肩代わり」は、実はVMware独自の発明ではなく、XCOPY(Extended Copy) というストレージ業界共通の標準コマンド(SCSI規格、ストレージ機器同士の会話のルールのようなもの)として、以前から定義されているものです。
ここでの「XCOPY」はストレージ業界の標準コマンド(EXTENDED COPY)であり、Windowsのファイルコピーコマンドxcopyとは名前が似ているだけの別物です。
またWindowsには、似た目的の技術としてODX(Offloaded Data Transfer) があります。ODXはXCOPYの新しい世代の仕様のサブセットで、本記事で扱うXCOPY(古い世代の仕様)とは仕様上の世代が異なる、別系統のものです。
もっと詳しい技術背景(SCSIプロトコルレベル)に興味がある方は、関連ユーティリティの開発者による技術解説(2014年時点)も参考文献としてどうぞ。
VMwareは、ESXiからこの標準コマンドを呼び出せるようにする窓口として VAAI(vSphere APIs for Array Integration) という仕組みを用意しています。つまり「VAAIという機能の中にXCOPYがある」というより、「元々ある業界標準のXCOPYを、VMwareがVAAI経由で使えるようにしている」という関係です。
上記サイトからの当該箇所の引用
( 2 ) 仮想マシンファイル ( 大容量 ) のコピー、移動が頻発
仮想環境には、仮想マシンがファイルであることを生かした便利な機能がたくさんありました。前回のブログでご紹介した Storage vMotion もその一つです。こういった便利な機能を利用するには、大容量の仮想マシンファイルをコピーしたり、移動したりする必要があります。VAAI が有効でない場合、この処理は ESXi サーバの CPU が行います。つまり、 ESXi サーバが対象となるデータをストレージから読み込み ( read ) 、再びストレージへ送って書き込む ( write ) という処理を行う必要がありました。このため、本来仮想マシンによって利用されるべき ESXi サーバの CPU リソースが奪われるうえ、サーバ – ストレージ間の帯域も一時的に逼迫してしまいます。
これに対し、VAAI が有効なストレージでは、ファイルコピーや移動の処理をストレージ単体で行うことが可能になります。ESXi サーバは、ただ一度命令を出すだけで済むので、CPU リソースが奪われることがありません。また、実際のデータは、ストレージ内でのみ流れることになるため、サーバ – ストレージ間の帯域も消費されません。これを実現している VAAI の機能を Full Copy と呼びます。
VAAI経由で肩代わりできる処理には、ディスクの複製(XCOPY)以外にも、ディスクのゼロ埋めや不要領域の解放などもあり、「オフロード」はコピーだけを指す言葉ではありません。
VMware環境では、以下のように3種類の処理をストレージ側に任せる機能をVAAIを通じて利用出来るようにしています。
【引用元】 新卒 SE 社員が贈る vSphere のキソ！第８回 ( 追加編 ) 〜 まだまだあった！ストレージ関連機能 〜 より
Red Hat MTVでは、上図内の真ん中の 「ファイルコピー」 を使用することで、一般的にVDDKよりも高速な仮想マシン変換を行うことが可能です。
Q. 「ストレージオフロード」と「ストレージコピーオフロード」は同じか？
A. これらの表現は区別して呼び分ける必要があります。
- 前者(ストレージオフロード) はストレージに対して処理を任せることそのものを言い、上図でいう3つ全ての処理を指します。
- 後者(ストレージコピーオフロード) は上記3つの中の真ん中の処理だけのことを指します。
Q. MTVとは何か（おさらい）
A. Red Hat OpenShiftユーザーが追加費用なしに使える、仮想マシンの引っ越し機能です。VMwareをはじめ複数の仮想化基盤から、OpenShift Virtualizationへ仮想マシンを移行できます。
Q. ストレージコピーオフロードとは何か
A. もうここまででずいぶん説明をした気がしますが、改めてこの項目で解説をします。
先ほどのXCOPYを使い、仮想マシンのディスクデータを、ネットワーク経由ではなくストレージ機器の内部で直接複製する仕組みです。
以下の図で言えば、オレンジの矢印が示すように、ストレージ筐体内でのデータ変換処理が実施されます。
ストレージオフロードを使用しない一般的な仮想マシンの移行は、ネットワーク経由の移行は「読み込み→ネットワーク転送→書き込み」という流れです。
下図で言うとオレンジの矢印が示す流れで仮想マシンの変換のための処理が流れます。
一連の処理に関わる要素がネットワークを始め、転送元と先のサーバ内での処理もあるため、パフォーマンスのボトルネックとなる要素や処理による影響を受ける箇所が多いため、本記事で取り上げているストレージ内での処理の方が効率が良いとは言いやすいです。
ストレージコピーオフロードでは、MTVがストレージ機器に対して「このデータを、機器の中で直接複製しておいて」と指示を出すだけで、実際の複製作業はストレージ機器の中で完結します。人間で例えると、荷物を自分で運ぶ代わりに、倉庫の管理者に「あそこの棚のものをこっちの棚に移しておいて」とお願いするイメージです。
裏側では、ESXi上のvmkfstoolsというコマンドを通じてXCOPYの指示が送られ、Forklift(MTVの構成部品)にある専用の仕組みがこのやり取りを仲介しています。
Q. なぜVDDKが無くてもストレージコピーオフロードは動作出来るのか
A. ストレージコピーオフロードは、ストレージ筐体内でデータの処理を行います。
VDDKを用いたデータ処理はストレージコピーオフロードとは異なり、ストレージからデータを取り出してネットワークを経由してVDDK内でデータの処理を実施しする方式です。
両者はデータの変換処理方法が全く異なり、共存もしません。
そのため、VDDKが手元になくても、オフロード対応するストレージ機器があれば高速に移行できます。
1つの移行プラン内で、VDDKを使う設定とストレージコピーオフロードを使う設定は混ぜて使うことができません。混在させると移行プランは失敗します。
Q. どんな移行先でも恩恵を受けられるのか？
A. いいえ。移行元・移行先の両方が、同じストレージ機器につながっていることが前提です。
例えば、Dell PowerStoreをVMware環境で使っており、そのままOpenShift Virtualizationのストレージとしても使う場合は、複製がPowerStoreという1つの機器の中で完結するため、恩恵を受けられます。
一方、移行先がRed Hat OpenShift Data FoundationやNutanix AHV、Azure LocalのようないわゆるSDS(Software-Defined Storage)/HCI型基盤(各サーバーが自前で持つディスクをソフトウェアでまとめて使う方式)の場合は注意が必要です。
理由は単純で、SDS/HCI型基盤の場合、仮想マシンの保存域はサーバ自身の内蔵ドライブとなるため、移行元の外部ストレージとは物理的に異なり、結果としてオフロードによる同一筐体内高速コピーが働きません。
その点、Red Hat OpenShift Virtualizationでは、主要ストレージベンダーの共有ストレージをCSI(Container Storage Interface)という仕組みを通じて連携する設計になっているため(参考)、今お使いの外部ストレージ機器をそのまま活かせるアーキテクチャだと言えます。
この点から言えば、現状VDDKの一般公開停止によって最も影響を受けているのはストレージオフロードが利用できないケースだと言えます。
執筆時点の情報です。各社が今後この課題に対応する可能性はあります。
Q. 対応しているストレージ製品はどこで確認できるか
A. 以下をご確認ください（内容は予告なく変更されます）。
2025年時点ではHitachi Vantara、NetApp ONTAP、Pure Storage FlashArray、Dell PowerMax/PowerFlex/PowerStore、HPE 3PAR/Primera、Infinidat InfiniBox、IBM FlashSystemなどが対象です。各社の事例・デモは末尾の付録にまとめました。
まとめ
- Red Hat OpenShiftにおいてMTVの移行はVDDKだけが選択肢ではありません
- 対応ストレージがあれば、ストレージコピーオフロードでネットワーク経由より高速・低負荷に移行できます
- XCOPYはVMware独自の機能ではなく、ストレージ業界共通の標準コマンドです。VAAIはそれを使うための窓口です
- VDDKとの混在は不可。方針は事前に統一を
- 恩恵は移行元・移行先が同じストレージ機器の場合に限られ、SDS/HCI型移行先では受けにくい可能性があります
- 対応ストレージの一覧は必ず最新の公式ドキュメントで確認を
付録：対応ストレージ各社の関連情報
各社（アルファベット順）が公開しているMTVストレージコピーオフロード関連のブログ・技術文書・デモです。各社独自の見解であり、Red Hatの公式見解ではありません。
Dell Technologies（PowerMax / PowerFlex / PowerStore）
- Red Hat OpenShift offload migration from VMware with Dell PowerMax
- OpenShift MTV PowerMax XCOPY patches
- OpenShift offload migration from VMware with Dell PowerFlex
- Red Hat OpenShift MTV Offload Plugin GA
Hitachi Vantara（VSP One）
- Accelerate virtual machine migration with MTV（Red Hat公式ブログ）
- Hitachi storage offload delivers faster data movement（Red Hat公式ブログ）
- Replatform Faster: OpenShift + VSP One Storage Offload（Hitachi Vantara公式ブログ）
- OCPV Migration to VSP One High End（Hitachi Vantaraコミュニティブログ）
- 動画：Storage Offload Video Tutorial
HPE（3PAR / Primera）
IBM（FlashSystem）
Infinidat（InfiniBox）
- プレスリリース：Infinidat Strengthens Relationship with Red Hat
- PDF：InfiniBox tested with Red Hat OpenShift Virtualization
NetApp（ONTAP）
- Move Your VMs to OpenShift Virtualization—The Shift Toolkit Way（NetAppコミュニティブログ）
- 公式ドキュメント：Migrate a VM from VMware to Red Hat OpenShift cluster
Pure Storage（2026年2月にEverpureへ社名変更）（FlashArray）
- FlashArray Simplifies VMware to Red Hat OpenShift Virtualization Migration（Everpure公式ブログ）
- Migrating Off VMware without the VDDK（Everpure公式ブログ）
- OpenShift MTV with FlashArray（Everpure公式技術文書）
- Beam Me Up, Scotty（第三者ブログ）
あとがき
移行方式を整理すると、「VDDKが使えるか」より「どんなストレージを使っているか」「移行先がその資産を活かせる構成か」の方が、実は速度や運用に直結する要素だと分かります。
VMwareからの移行を検討中の方は、まずお手元のストレージがストレージコピーオフロードに対応しているか確認してみることをお勧めします。