移行 · VMware
VMware仮想マシンをApache CloudStackへ移行
Apache CloudStackはVMware vCenterから仮想マシンをインポートでき、バージョン4.19以降ではKVMへの変換も可能です。安全に実施するには、インベントリの作成、移行先ゾーン、検証、マシンごとの切り替え計画が依然として不可欠です。NexCMP Sourceに含まれる30営業日の中で、専門エンジニアが追加料金なしでお客様とともにその作業を進めます。
NexCMP Source（買い切り$499）に含まれます（NexCMP Freeには含まれません）。VMware、WHMCS、HostBill、Blesta、Paymenter、StackBill、VirtualizorおよびApache CloudStackは、それぞれの所有者の商標です。NexCMPは独立しており、これらと提携または支持されているものではありません。
課題：制御を維持したままVMwareから移行する
Apache CloudStackへの移行では、すべての仮想マシンのプラットフォーム（ディスク、ネットワークカード、ドライバー、そして多くの場合IPアドレス）が変更されます。急いで進めると、マシンの起動失敗、顧客のアクセス喪失、ライセンスの無効化といった問題が発生します。
CloudStackはインポートツールを提供しますが、どのマシンを優先するか、各ネットワークをどうマッピングするか、Windowsゲストをどう扱うか、各マシンの停止時間をどうするかまでは判断してくれません。これらの決定とそれに伴う検証こそが、移行そのものです。
仮想マシンを顧客に販売している場合、移行にはもうひとつの重要なプロセスがあります。請求システム上でマシンを適切な顧客、プラン、価格に紐付け直す必要があります。NexCMPはCloudStack上の請求およびカスタマーポータル層であり、同一のエンジニアがこれら双方のプロセスを担当します。
CloudStack単体でサポートされる機能
VMwareからの移行には、ドキュメント化された2つのルートがあります。どちらが適しているかは、VMwareホストをクラウド環境に残すかどうかによって決まります。
A. virt-v2vによるKVMへの変換
- CloudStackドキュメントの記載内容
- バージョン4.19以降、管理者は既存または外部のvCenterデータセンター内のVMware VMを選択し、「ツール」>「Import-Export Instances」からKVMクラスターへインポートできます。VMはエクスポートされ、virt-v2vで変換された上で、ディスクがQCOW2としてインポートされます。最新のドキュメントでは、OVFベースの方式に加えてVDDKベースのストリーミング方式が追加されました。バージョン4.22ではストレージプールへの直接変換が、バージョン4.22.1では移行元ゲストOSに基づくゲストOSの自動選択が追加されています。
- ドキュメントに記載されている制限事項
- virt-v2vはCloudStackエージェントによってインストールされないため、各KVMホストに手動でインストールする必要があります。未導入の場合は変換に失敗します。変換の成功は保証されておらず、ゲストOSやファイルシステムに依存するため、ドキュメントでは本番環境への適用前に検証することを推奨しています。バージョン4.19では、インポートされたVMのゲストOSタイプがデフォルトでCentOS 4.5（32-bit）となるため、後から変更する必要があります。
Source: Apache CloudStack — VMware仮想マシンのKVMへのインポート · アクセス日 2026-10-19
B. インプレースインポート（未管理Instances）
- CloudStackドキュメントの記載内容
- ホストがすでにCloudStackの一部となっているvSphereクラスターでは、listUnmanagedInstancesでVMを一覧表示し、importUnmanagedInstanceによってCloudStackの管理下に置きます。未管理のVMware Instancesの一覧表示は4.14で、管理対象からの除外は4.15で、UIからのインポートは4.16で導入されました。
- ドキュメントに記載されている制限事項
- 移行先ネットワークがあらかじめCloudStackに存在し、ストレージがプライマリストレージとして追加されている必要があります。データディスクはディスクオファリングにマッピングする必要があり、ディスクコントローラーの種類の混在やNICタイプの混在はエラーの原因となります。稼働中のVMは、ネットワークVLANとコンピュートオファリングが一致する場合にのみインポート可能です。それ以外の場合は、事前に停止する必要があります。
Source: Apache CloudStack — Import Export Instancesについて · アクセス日 2026-10-19
移行先がKVMの場合はルートAを適用します。NexCMPのドキュメントでも検証済みハイパーバイザーとしてKVMを挙げているため、CloudStack配下にVMwareホストを残す構成でない限り、ルートAを計画します。実行しているCloudStackのバージョンをご確認ください。上記ページに記載のとおり、4.19と最新リリースでは動作が異なります。
移行対象と注意点
ディスク
- 動作内容
- QCOW2に変換され、移行先のプライマリストレージプールにインポートされる（ルートA）、またはCloudStackのディスクオファリングにマッピングされます（ルートB）。
- 注意事項
- ルートBでは、ディスクオファリングのサイズがより大きくてもディスクのリサイズは行われません。ルートAの変換中の一時ストレージはデフォルトでセカンダリストレージとなり、プライマリストレージを使用できるのはNFSの場合に限られます。
Source: Apache CloudStack — VMware仮想マシンのKVMへのインポート · アクセス日 2026-10-19
ネットワーク
- 動作内容
- インポート前にネットワークがCloudStackに存在している必要があります。ディスカバリースクリプトによって、1台以上のVMが接続されているvCenterネットワークが一覧表示されるため、対応するネットワークを事前に作成できます。
- 注意事項
- virt-v2vはゲストのネットワーク設定を再構成したり、MACアドレスを変更したりすることはできません。移行先のサブネットが異なる場合は、変換後にゲスト側での変更作業が必要です。
Source: libguestfs — virt-v2v マニュアル · アクセス日 2026-10-19
Linuxゲスト
- 動作内容
- 稼働中のLinux VMはルートAでインポートできます。CloudStackがエクスポート前にクローンを作成するため、クラッシュ整合性のある状態で変換されます。
- 注意事項
- CloudStackのドキュメントでは、まずLinux VMの電源をオフにすることを推奨しています。virt-v2vは新しいカーネルやドライバーをインストールせず、virtioサポートがない場合は警告を発するため、ゲストは変換前に最小要件のバージョンを満たしている必要があります。
Source: libguestfs — virt-v2v マニュアル · アクセス日 2026-10-19
Windowsゲスト
- 動作内容
- ルートAでインポートする前に正常にシャットダウンする必要があります。virtioドライバーはvirtio-winパッケージから取得され、初回起動時にインストールされます。初回起動後、Windowsは4回以上再起動する場合があります。
- 注意事項
- 高速スタートアップや休止状態が有効な場合は変換できず、ダイナミックディスク上のシステムディスクはサポートされません。Windowsのインポートには変換ホスト上にvirtioドライバーが必要です。
Source: libguestfs — virt-v2v マニュアル · アクセス日 2026-10-19
VMware Tools
- 動作内容
- virt-v2vはVMware Toolsの削除を試行します。
- 注意事項
- マニュアルによると、Windowsでは削除が正常に動作しない場合があり、別の方法でToolsを削除する必要がある可能性があります。
Source: libguestfs — virt-v2v マニュアル · アクセス日 2026-10-19
ゲストOSタイプ
- 動作内容
- インポートされたVMにはデフォルトのゲストOSタイプが割り当てられます。
- 注意事項
- 4.19ではCentOS 4.5（32-bit）となるため手動で変更する必要がありますが、バージョン4.22.1ではマッピングが存在すれば移行元のゲストOSからマッピング可能です。
Source: Apache CloudStack — VMware仮想マシンのKVMへのインポート · アクセス日 2026-10-19
請求と顧客管理
- 動作内容
- プラン、価格、顧客アカウントをNexCMPで設定し、移行された各マシンを適切な顧客に紐付けます。
- 注意事項
- ご使用のCloudStackバージョンに合わせて第1週で合意します。これはNexCMP側の作業であり、CloudStackの機能ではありません。
週ごとの実施計画
一般的なスケジュール例であり、状況に応じて調整されます。30営業日の継続作業は約6週間に相当します。
第1週 — 現状把握と方針決定
vCenterへの読み取り専用アクセスを使用して、すべてのVM（ゲストOS、ディスク、ネットワークカード、VLAN、Snapshots、電源状態、依存関係）を棚卸しします。ルートAまたはBを選択し、移行ウェーブを定義した上で、Windowsゲスト、大容量ディスク、固定ライセンスを持つものなど、特別な配慮が必要なマシンを特定します。
第2週 — 移行先環境の構築
CloudStackゾーンの確認または構築を行います（KVMホスト、ストレージ、VMware環境に合わせたネットワーク）。KVMホストにvirt-v2v（Ubuntuホストにはnbdkitも）をインストールし、Windows用のvirtioドライバーを準備して、変換ホストとvCenterおよびESXi間のネットワーク経路を開通させます。マシンを販売している場合は、同週内にNexCMPをインストールしてCloudStackに接続します。
第3週 — パイロット移行
保有するゲストの種類ごとに1台ずつ、非クリティカルなマシン数台を使って実際の移行手順を実施します。起動確認、ネットワーク疎通、適切なドライバーの適用確認、ゲストOSタイプの設定を行い、各マシンの停止時間を計測します。この結果をもとに、本番ウェーブのメンテナンス枠を確定します。
第4〜5週 — 段階的移行（ウェーブ）
合意した日時に合わせて、マシンをグループ単位で移行します。次のグループを開始する前に各グループの動作確認を行い、移行元のVMwareマシンは切り戻しができるよう電源をオフにした状態で保持します。マシンを販売している場合は、並行してNexCMPで顧客、プラン、価格を設定し、本番切り替え前に課金処理を並行稼働させます。
第6週 — 最終切り替えと引き渡し
残りのマシンを移行し、販売している場合は請求日を切り替え、DNSの変更を実施します。実施した全作業内容をドキュメント化し、セキュリティ強化とBackupsの確認を行い、30営業日の終了まで移行後のサポート待機を継続します。
本スケジュールは概要です。実際の計画は第1週に策定され、本提案において日程がコミットされているのは30営業日の作業期間のみとなります。
リスクとその軽減策
リスクのない移行は存在せず、ダウンタイムゼロをお約束するものでもありません。以下に発生しうる問題と、それに対する当社の対応策を記載します。
マシンごとのダウンタイム
稼働中のWindowsマシンは変換できず、稼働中のLinuxマシンはクラッシュ整合性の状態で変換されます。CloudStackは変換所要時間を定めていません。パイロット段階で所要時間を計測し、マシンのグループごとに停止枠を合意します。
変換が成功しない場合
CloudStackでは成功は保証されておらず、ゲストに依存すると記載されています。本番ウェーブの前にパイロットですべての種類のゲストを検証し、移行元のマシンは新しいマシンの確認が完了するまで手を加えずに維持します。
ドライバーとVMware Tools
Windowsマシンには変換時にvirtioドライバーが導入され、Linuxマシンには事前にvirtioサポートが必要であり、VMware Toolsは手動削除が必要になる場合があります。これらはパイロット時にゲストごとに検証します。
IPアドレス、MACアドレス、DNS
ゲストは自身のMACアドレスとネットワーク設定を保持するため、移行先でサブネットが異なる場合はゲスト内部での変更が必要です。第1週にすべてのアドレスをリストアップし、切り替え前にDNSのTTLを短縮して、事前にお客様の顧客へ案内します。
ゲストのソフトウェアライセンス
マシン内のWindowsや商用ソフトウェアのライセンスは、以前のプラットフォームに紐づいている場合があります。移行前に各ベンダーとの契約条件をご確認いただけるよう、インベントリ一覧に記載します。
変換処理の中断
CloudStackの仕様上、移行中に管理サーバーを再起動すると処理が中断され、インポートの再実行が必要になります。弊社ではメンテナンス時期を避けて移行ウェーブをスケジュールし、実行中の再起動を防止します。
請求の切り替えとロールバック
マシンを販売されている場合、請求の切り替え日はご相談の上で決定し、まずは両システムを並行稼働させます。移行完了の合意をいただくまでVMwareの元環境は保持されるため、どのグループでも確実に切り戻しが可能です。
役割分担
読み取り専用のvCenterアクセス権および重要マシンのリスト
- 担当エンジニアの作業範囲
- 全VMの棚卸しと移行ウェーブの計画
CloudStack環境とKVMホストへのアクセス権、またはそれらを構築するためのハードウェア
- 担当エンジニアの作業範囲
- ゾーン、ネットワーク、変換ホストの準備
選択した移行ルートに必要なVDDKおよびvirtioパッケージ（ベンダー規約により直接ダウンロードが必要な場合）
- 担当エンジニアの作業範囲
- 変換ホストへのインストールと動作検証
合意された停止枠とお客様のエンドユーザーへの事前通知
- 担当エンジニアの作業範囲
- パイロット移行および各ウェーブの実行、移行後の全マシン検証
マシンを販売されている場合の価格設定方針
- 担当エンジニアの作業範囲
- NexCMPでのプラン、顧客、請求の設定と並行運用期間の実施
30営業日のサポートに含まれる内容
本移行はNexCMP Sourceアップグレード（1回限り $499）に含まれます。これには完全なソースコード（Rustサーバー、Vueポータルおよび管理者画面、Goノードエージェント、CLI、ビルドスクリプト）、無制限の改変・独自ビルド権、12か月間の新規ソースリリース、すべてのアプリ、専任エンジニアによる30営業日の継続的な支援が含まれます。
この30営業日の間、専門エンジニアが追加料金なしでVMwareからApache CloudStackへの移行を実施します。あるいは、この期間をWHMCSなど他のシステムからの移行や、ゼロからの完全セットアップ、独自アプリの構築に充てることも（併用することも）可能です。期間のカウントは専任エンジニアとの作業開始時からスタートし、ライセンスページに表示されます。移行サポートの有効期間も同様に30日間です。
NexCMP Freeには本サービスは含まれません。Freeは全モジュールを1年間無料で利用でき、テクニカルサポートはなくソースコードのバグ修正のみが提供され、年額 $99 で更新されます。
VMwareからCloudStackへの移行 — よくある質問
費用はいくらですか？
NexCMP Freeにも含まれていますか？
サポートされているCloudStackおよびVMwareのバージョンは？
仮想マシンのダウンタイムは発生しますか？
すべてのVMを変換できますか？
移行後もVMware環境を維持する必要がありますか？
提供が必要なものは何ですか？
情報源と注記
技術的な記載は公式のApache CloudStackドキュメントおよびvirt-v2vのマニュアルに基づいています。ドキュメントの内容はリリースごとに異なるため、稼働中のバージョンをご確認ください。4.19に関する記載は、VMwareからKVMへの移行ページが「As of CS 4.19」で始まる4.19のドキュメントに基づいています。VMware、WHMCS、HostBill、Blesta、Paymenter、StackBill、Virtualizor、およびApache CloudStackはそれぞれの所有者の商標です。NexCMPは独立しており、これらと提携または承認を受けているものではありません。
専任エンジニアとともにVMwareからの移行を
$499でNexCMP Sourceにアップグレードして30営業日のサポートを開始するか、まずは[email protected]までお客様の環境についてお問い合わせください。
最終更新: