VMwareからIBM Cloud VPC VSIへ（パート3）：仮想マシンの移行

Last updated at 2026-06-11Posted at 2025-11-14

本記事は、原著者の許可を得て以下のリンクを翻訳したものです。翻訳内容に誤りがある場合、その責任は翻訳者にあります。また記事によっては、訳語を適宜Qiitaで読みやすいように段落分け、カテゴライズ分けをして記述しているものもありますのでご了承ください。

https://fullvalence.com/2025/11/10/from-vmware-to-ibm-cloud-vpc-vsi-part-3-migrating-virtual-machines/

このシリーズの全てのブログ記事はこちらです：

本記事では、VMware から IBM Cloud VPC VSI へ仮想マシン全体をシンプルに「リフト＆シフト」で移行する方法について説明します。この方法は汎用的ですが、状況によっては他の選択肢がより適している場合もあります。例えば、自動デプロイの運用が確立されている場合は、移行時に新しい仮想マシンをIBM Cloud上にデプロイし、データを移行するようにプロセスを見直すことも検討すべきです。

現在、VMwareワークロードをIBM Cloud VPC VSIに「ウォームマイグレーション」するための簡単な方法はありません。元の仮想マシンを停止し、ディスクをエクスポートして少なくとも1回は最終的な宛先に転送するための十分な停止時間を計画してください。

2025年12月3日更新:
・cloud-init の利用方法に関するガイダンスを変更
・Red Hat に関する注意事項を追記
・Windows に関する考慮点を再構成・整理

2026年1月23日更新:
新たに利用可能となった追加リソースへのリンクを追加しました。

制限事項

現在、12個を超えるディスクを持つVSIを作成することはできません。また、VSIのブートディスクを10GB未満または250GBを超えるサイズにすることもできません。
もしブートディスクが250GBを超えている場合は、移行の前に仮想マシンを再構成する必要があります。
VPC VSIは共有ブロックボリュームをサポートしていません。一部の共有ストレージのユースケースでは、File Storage for VPCを利用して、複数の仮想マシンにアタッチすることができる場合があります。このブログ投稿では、そのような共有ファイルをVPCファイルストレージに移行する方法については扱っていません。
もしクラスターファイルシステムとして使用するための共有ブロックストレージが必要な場合は、独自のVSIをデプロイし、それを使用して他のVSIにiSCSIターゲットを公開する方法を取ることができるかもしれません。
VSIでFSTRIMを使用しても問題はありませんが、何の効果もありません。

訳者注: FSTRIM は Linux のファイルシステム管理コマンドで、未使用領域をストレージに通知するために使われます。ファイルシステムが削除した領域は通常 OS 内部で「未使用」とマークされますが、ストレージには通知されません。FSTRIM はその未使用領域をストレージに「TRIM」コマンドで伝えます。VPCではストレージ領域がクラウド基盤で管理されており、TRIM 情報を受け取ってもクラウド側で特別な処理をしないため、容量削減にはつながらないようです。

準備

システムを準備する際には、概ね次の手順を実施する必要があります。

(1) VMware Tools のアンインストール
(2) virtio ドライバーのインストール
(3) cloud-init のインストール、
(4) ネットワーク設定のリセット

IBM Cloud には、Classic VSI から VPC VSI への移行に関する既存のドキュメントがあり、これらの多くのポイントをカバーしています。

VSI の初期セットアップは cloud-init に依存しているため、たとえ真の意味での初回起動ではない状況であっても、初回起動時と同様にシステム構成の一部が cloud-init によって変更される可能性があることを意味します。たとえば、root または Administrator パスワードがリセットされたり、authorized_keys（SSH 公開鍵）が再生成されたり、SSHD 設定が再構成されたり、ホストキーが再生成される可能性があります。
そのため、cloud-init の設定内容と、その副作用を慎重に確認・調整・テストし、これらの挙動に備えておく必要があります。

Linuxでの考慮事項

Linux では、Windows と比べると virtio のインストールはずっと簡単で、手作業でも十分に実施できます。とはいえ、後述する手順の通り virt-v2v ツールを使う方法を推奨します。

もし RHEL を利用していて、（後ほど詳しく説明しますが）ライセンスを持ち込むのではなく IBM Cloud 側のライセンスを利用する構成を選んだ場合、IBM Cloud の VSI 自動処理は、システムが IBM Cloud のサブスクリプションに登録され、想定されているシステム UUID を使用していることを前提に動作します。
そのため、/etc/rhsm/facts/uuid_override.facts というファイルが存在し、UUID を上書きしていないか確認してください。もしあれば削除してください。

ネットワーク設定については、cloud-init と DHCP によって初期化が行われます。その際、インターフェース名が変更されるケースがあります。古いネットワーク設定が残っていると、ネットワークが正しく立ち上がらないことがあり、たとえばデフォルトのネットワーク経路が取得できないといった問題につながる可能性があります。そのため、不要なネットワーク設定は可能な限り削除しておくべきです。RHEL 9 の一般的な環境では、以下の作業を行います：

/etc/sysconfig/network-scripts 配下のファイルを削除する
/etc/NetworkManager/system-connections 配下のファイルを削除する
/etc/sysconfig/network を確認し、GATEWAYDEV の項目が設定されていないことを確かめる

初回起動時に、デフォルトルートを含むネットワーク接続を確立できない場合、cloud-init による登録処理が失敗する可能性があります。

Windowsでの考慮事項

Windows の場合、virtio ドライバーのインストールにはいくつか重要な注意点があります。

まず、ドライバーは Red Hat から入手する必要があります。その 1 つの方法として、RHEL の VSI をデプロイし、virtio-win パッケージをインストールし、このパッケージによって配置される ISO ファイル（各種 OS 用ドライバーを含む）を取得するやり方があります。手順についてはいくつかの参考情報があります。私はこの ISO を Windows VM にコピーし、ドライブとしてマウントし、ISO 内の virtio-win-gt-x64 と virtio-win-guest-tools を実行しました。
2つ目の注意点としてドライバーのインストールだけでは不十分だということです。たとえ Windows VM に virtio ドライバーをインストールしたとしても、通常ドライバーは特定のデバイスに紐づいているため、そのまま VPC VSI として起動しても正常にブートしない可能性があります。対応方法としては次の 2 つがあります。
- １つは、Microsoft の sysprep を使用し、移行直前に仮想マシンを「一般化（generalize）」する方法です。IBM Cloud の VSI ドキュメントでもこの方法が推奨されています。このやり方は、デバイスドライバーの紐付けが解除されるという利点がありますが、その一方で多くの副作用もと制限事項もあるため注意が必要です。
  Windows System Image Manager を使用して unattended answer file を作成すれば、sysprep の動作をある程度制御できます。
- もう 1 つの方法は、後述する libguestfs ツールを使用しimageを準備する方法です。このツールキットは、Red Hat の Migration Toolkit for VMware (MTV) の基盤となっており、以前の記事で RedHat OpenShift Virtualization への仮想マシン移行で使用される際に見たものです。virtio ドライバーを組み込むことも可能ですし、Windows にそれらを強制的に使用させることも可能です。MTV の利用環境以外で libguestfs ツールを使用する際には、いくつか重要な注意点がありますので、以下で見ていくことになります。この方法を取る場合は、Windows システムを必ず正常にシャットダウンしておいてください。 Windows VM が正常に停止されていない場合、virt-v2vは処理を行いません。
私はどちらの方法でも Windows VM の VSI 移行に成功しましたが、後者の方法が好みです。
3つ目の注意点は、ドライバーはブートディスクと回復イメージ（Recovery Image）の両方にインストールされている必要があることです。特に、virt-v2v はブートディスクにしか対応しない点に注意してください。回復イメージについては IBM Cloud のドキュメントにも記載があります。私の検証では以下の追加の注意点がありました。
- 回復イメージが必ずしも回復ボリューム上に存在するとは限りません。実際、私の環境では reagentc により回復ボリューム上にあると報告されていましたが、そのボリュームは空で、実際のファイルはC:\Windows\system32\Recovery にありました。
- ドライブが MBR ではなく GPT でフォーマットされている場合は、次の点に注意が必要です：
  - list partition および select partition の代わりに、list volume および select volume を使用する必要があります。
  - また、データボリュームとシステムボリュームを区別するために ID を 07 や 27 に設定する代わりに、まず ID を ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 に設定し、その後に c12a7328-f81f-11d2-ba4b-00a0c93ec93b に設定する必要があります。

訳者注：

reagentcはトラブル発生時に複数の修正方法を実行する起動（復元）用OS「WinRE」（Windows Recovery Environment: Windows回復環境）を操作するコマンドです。おそらくreagentc /infoの実行結果を指しているのだと思われます。
https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/reagentc-command-line-options?view=windows-11
list partitionやlist volumeコマンドは、diskpartユーティリティー内のコマンドです。ただ、私の理解が間違っているのかもしれませんが、あくまでlist volumeコマンドはCドライブなどのボリュームを出力するものであり、list partitionはディスクパーティションを出力するものであって、MBRとかGPTとかとは関係ないと思うのですが。実際、MBRでもlist volumeコマンドやlist partitionコマンドは使えているので。。。

PS C:\> diskpart

Microsoft DiskPart version 10.0.20348.1

Copyright (C) Microsoft Corporation.
On computer: TESTWIN03

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          100 GB      0 B
  Disk 1    Online          378 KB   378 KB
  Disk 2    Online           44 KB    44 KB

DISKPART> list volume

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0         System Rese  NTFS   Partition    100 MB  Healthy    System
  Volume 1     C                NTFS   Partition     99 GB  Healthy    Boot

DISKPART> list partition

There is no disk selected to list partitions.
Select a disk and try again.

DISKPART> select volume 1

Volume 1 is the selected volume.

DISKPART> detail volume

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
* Disk 0    Online          100 GB      0 B

Read-only              : No
Hidden                 : No
No Default Drive Letter: No
Shadow Copy            : No
Offline                : No
BitLocker Encrypted    : No
Installable            : Yes

Volume Capacity        :   99 GB
Volume Free Space      :   76 GB

DISKPART> select disk 0

Disk 0 is now the selected disk.

DISKPART> list partition

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    Primary            100 MB  1024 KB
  Partition 2    Primary             99 GB   101 MB

DISKPART> select partition 2

Partition 2 is now the selected partition.

DISKPART> detail partition

Partition 2
Type  : 07
Hidden: No
Active: No
Offset in Bytes: 105906176

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
* Volume 1     C                NTFS   Partition     99 GB  Healthy    Boot

MBR形式においては、07はNTFS または exFAT の「データパーティション」を、27はWindows 回復パーティションを指します。
一方で、GPT形式においてはebd0a0a2-b9e5-4433-87c0-68b6b72699c7はベーシックデータパーティションを、c12a7328-f81f-11d2-ba4b-00a0c93ec93bはEFI システムパーティションを指します。
https://learn.microsoft.com/ja-jp/windows-server/administration/windows-commands/set-id

4つ目の注意点は、IBM Cloud の VSI には特別な仕様があり、Windows のブートディスクは virtio SCSI デバイスとして提示される一方、それ以外のボリュームはすべて virtio ブロックデバイスとして提示されることです。これは、非 Windows の VSI ではすべてのボリュームがブロックデバイスとして提示される仕様とは対照的です。このことが意味するのは、libguestfs を使って virtio ドライバーを注入する場合、ブートドライブを SCSI として扱うように強制する特別なパラメーターを指定する必要があるということです。
使用すべきパラメーターは次のとおりです：--block-driver virtio-scsi
5つ目の注意点は、Red Hat が提供する Windows 向け virtio ドライバー対応バージョンは以下に限定され流ことです。

- Windows Server 2008 R2
- Windows Server 2012
- Windows Server 2012 R2
- Windows Server 2016
- Windows Server 2019
- Windows Server 2022
- Windows Server 2025
- Windows 7
- Windows 8
- Windows 8.1
- Windows 10
- Windows 11

(訳注：6つ目の注意点?)virtio に関する対応に加えて、cloudbase-init をインストールしてください。なお、私の経験では、ネットワーク設定に関しては Linux よりも Windows の方が問題が少ないと感じています。

VSIイメージとブートボリューム

VSIを作成すると、そのVSIのために既存のイメージテンプレートに基づいたブートボリュームが作成されます。
ブートボリュームは、プロセッサーアーキテクチャやオペレーティングシステムなどの属性を示す特別な種類のストレージボリュームです。また、ブートボリュームは元のイメージのリンククローン（linked clone）として、容量効率の高い形式で存在します。このブートプロセスにはいくつかのバリエーションがあり、たとえば以下のような方法を取ることができます。

カスタムイメージを使用してブートボリュームを作成する
別のブートボリュームのスナップショットをイメージテンプレートとして利用する
既存のVSIに接続されていないブートボリュームを再利用する

なお、現時点ではISOイメージを使用してVPC VSIを起動することはできません。 これらの機能を組み合わせることで、仮想マシンのディスクをインポートする際にいくつかの異なるアプローチを取ることが可能になります。

移行方法

VMware VMをVPC VSIへ移行するには、大きく分けて4つの方法があります。

VMware VMのディスクをエクスポートし、それをIBM Cloudにイメージとしてインポートして、そのイメージを使用してVPC VSIを起動する方法
VMware VMのディスクをエクスポートし、それをIBM Cloudのブロック・ストレージ・ボリュームにコピーして（必要に応じてイメージを準備するために virt-v2v を使用）、そこからVPC VSIを起動する方法
VMware VMをISOイメージを使用してブートし、ディスクを読み取り転送できるようにしてから、そのディスクをIBM Cloudのブロック・ストレージ・ボリュームへコピーすることができる環境に転送し（必要に応じてイメージを準備するために virt-v2v を使用）、そこからVPC VSIを起動する方法
※ あらかじめお伝えしておくと、このやり方が私が最も推奨する方法です。
vCenterから直接、virt-v2v の VDDK(VMware Virtual Disk Development Kit) 機能を使ってVMware VMを抽出し、IBM Cloudのブロック・ストレージ・ボリュームにコピーし、そこからVPC VSIを起動する方法

以下の図は、これらのアプローチを視覚的に示したものです。

当然ながら、これらの方法にはいくつかの注意点があります。まず、共通する一般的な注意事項について説明し、その後で各移行方法について詳しく見ていきます。

libguestfs の使用について

libguestfs ツールキットは非常に強力で、以下の機能があります。

virt-v2vは、あなたのローカルディスク上の仮想マシンイメージを変換できます。その際、virtio ドライバーのインストールもすることができます。
nbdkit VDDK プラグイン と組み合わせることで、virt-v2v は vCenter や vSphere ホストに直接効率的に接続することができます。そして、イメージを抽出し、変換して、あなたのローカルディスク上に出力することが可能です。
virt-p2v は、ソースのVMware VMを起動する際に使用するISOイメージの一つとして利用でき、変換処理とローカルディスクへのコピーを行うターゲット環境への接続を可能にします。

しかし、利用する際にはいくつか重要な注意点があります。

libguestfs のツール群は、qemu-kvm を使って仮想マシンを一時的に起動し、その仮想マシンにディスクをアタッチした状態で各種処理を実行しているようです。IBM Cloud の VSI でこれらのツールを使う場合、ネストされた仮想化は正式にはサポート対象外である点に注意が必要です。ただし、私が試した限りでは特に問題は発生していません。もし気になるようであれば、変換作業用の環境として VPC のベアメタルサーバーを利用することもできます。
Windows VM を移行する場合については、virt-v2v が virtio ドライバを導入する際に必要となる virtio-win パッケージは RHEL にしか含まれていません。そのため、作業は RHEL 上で行うか、あるいは RHEL から /usr/share/virtio-win ディレクトリをコピーして使用する必要があります。
RHEL ビルドの virt-v2v には、IBM Cloud 上の Windows システム向けドライバの準備に必要な --block-driver virtio-scsi オプションがサポートされていません。対応するには、libguestfs を自分でビルドするか、あるいは RHEL 以外のシステム（例：Ubuntu）上で virt-v2v を実行する必要があります。
RHEL ビルドの libguestfs には nbdkit VDDK プラグインが含まれますが、Ubuntu ビルドには含まれていません。Ubuntu を使用する場合は VDDK 方式を利用できないか、もしくは libguestfs を自前でビルドする必要があります。
Ubuntu は virt-v2v-in-place を提供しますが、RHEL には含まれていません。このコマンドは、不要なコピーを避けたい特定のシナリオで有用です。
virt-v2v は、仮想マシンのディスク出力先を「ファイル」ではなく「ディレクトリ」で指定する設計になっています。そのため、出力を直接 /dev/vdX デバイスに書き込むことは通常できません。しかし、シンボリックリンクを使えば、この制限を回避できます。例えば、仮想マシン smoonen-win のブートディスク名が smoonen-win-sda になると分かっている場合、次のように実行できます。

ln -fs /dev/vdb /tmp/smoonen-win-sda
virt-v2v -i disk smoonen-win.img -o disk -os /tmp --block-driver virtio-scsi

エクスポートに関する一般的な注意事項

これから説明する方法のすべてが、仮想マシンのエクスポートを必要とするわけではありません。ただし、仮想マシンをエクスポートする場合には、いくつか重要な点に注意する必要があります。

VCFaaS から仮想マシンをエクスポートする場合
- VCFaaSから仮想マシンをエクスポートする場合、vAppを停止し、「ダウンロード」を実行する必要があります。これにより、OVAファイルのダウンロードが開始されます。OVAファイルはZIP形式であり、その内容には仮想マシンのOVFディスクリプタと、VMディスク用のVMDKファイルが含まれています。その後の手順で、VMDKファイルを抽出してください。
vCenter から仮想マシンをエクスポートする場合
- vCenterから仮想マシンをエクスポートする場合、まず仮想マシンを停止する必要があります。データストアブラウザを使えばVMDKファイルをダウンロードできますが、この方法では最終的にシックプロビジョニングされたVMDKになってしまうようです。代わりに、「Actions -> Template -> Export OVF Template」を使用することをお勧めします。この方法ではシンプロビジョニングが保持されるようです。

一般的にOVF exportをすると、元のディスク形態がthin/thici/eager-zeroed thickのいずれであろうと、specialized sparse format（実質的なthin)になるようです。

参考:

方法 1：エクスポートした仮想マシンをVSIイメージとしてインポートする

仮想マシンにディスクが 1 つしかない場合、単純なアプローチとして、VMDK ファイルからイメージテンプレートを作成し、そのイメージを使って新しい VSI を起動するという方法があります。この方法は比較的シンプルで、VPC VSI のドキュメントでも説明されています。VMDK ファイルの場合の手順は次のとおりです。

VMDK を QCOW2 に変換します（例）：
qemu-img convert -f vmdk -O qcow2 smoonen-ubuntu-1.vmdk smoonen-ubuntu-1.qcow2
IBM Cloud コンソールで Infrastructure -> Storage -> Object Storage に移動します。
既存の COS インスタンスとバケットを探すか、新しいものを作成します。
Upload（アップロード） をクリックします。 QCOW2 イメージをアップロードするためには、「大容量ファイルの Web アップロード」を有効化するか、またはAspera をインストールして使用する必要があります。
イメージを VPC イメージサービスに公開する方法はいくつかありますが、最も簡単なのは COS バケットに対して public object reader アクセス権限を有効にすることです。
Infrastructure -> Compute -> Images に移動します。
希望するリージョンを選択します。
Create をクリックします。
名前を入力します（例：smoonen-ubuntu-migrated）。
COS を選択し、イメージの URL を指定します。
適切な OS 種類を選択します（BYOL と非 BYOL がある点に注意）。
イメージをどのように暗号化するかを選択します。なお、イメージの暗号化は VSI のディスク暗号化とは独立しています。

ただし、この方法にはいくつかの注意点と欠点があります。先に述べたように、この方法では 単一ディスクしか移行できません。追加のディスクがある場合は、以下で説明する別の手法を使う必要があります。

さらに根本的には、この方法は「イメージ」という概念本来の用途を乱用しています。本来イメージは再利用可能なテンプレートとして使われるべきものです。しかしこの方法では、仮想マシンごとに 1 つのイメージテンプレートを作成することになり、これにはいくつかの影響があります。

まず、イメージに cloud-init がインストールされている場合、これが初回ブートとして扱われる可能性があります。その結果、root パスワードのリセット など、望ましくない動作が発生するおそれがあります。

また、IBM Cloud において、イメージとブートボリュームはある種のリンククローンのような関係で存在しています。ブートボリュームは、イメージとのリンクによって容量効率を得ています。これはつまり、VSI が稼働している間は、そのイメージを削除することはできないということを意味します。

そしてさらに、この方法では仮想マシンごとに個別のイメージを作ることになるため、カスタムイメージ一覧が大量の使い捨てオブジェクトであふれてしまいます。 オッカムのウィリアムは、それを良しとしないでしょう。。

訳者注: オッカムのウィリアムは節約の原理である「オッカムの剃刀（Occam's razor）」であり、“必要以上にものごとを増やすな、シンプルにせよ”という原則を提示したことで有名です。

方法 2：エクスポートした仮想マシンを VPC ボリュームへコピーする

ディスクを VPC イメージとしてアップロードする代わりに、別のVSIに一時的にアタッチして作業を行うことで、VMware VM のディスクを直接VPC ボリュームへ書き出すこともできます。このプロセスは、まず最初にボリュームを作成するためだけに短命の（エフェメラルな）VPC VSIを作成して削除しなければならないため、やや複雑です。オプションでのやり方ではありますが、この手順において、仮想マシンのテンプレートをカスタムVSIイメージとしてアップロードすることで、リンククローンによるスペース効率を活用することもできます。手順は以下のとおりです。

オプション：仮想マシンの元のディスクテンプレートがある場合は、上記の方法1の手順に従って、このテンプレートをカスタムイメージとしてインポートしてください。後述のステップ3でこのカスタムイメージをブートボリュームの基盤として使用すると、両者のリンクによってストレージ効率が向上します。
作業用として、VMDKファイルを保持できる十分な容量を持つディスクまたはセカンダリディスクを備えた作業用VPC VSIを作成します。仮想マシンの VMDK をこの VSI にコピーします。
移行対象のVMを模倣したエフェメラルVSIを作成します。適切なOSとディスク構成を設定します。ネットワーク構成は使い捨てでも問題ありません。なお、デフォルトではIBMライセンスのオペレーティングシステムになりますが、カスタムの BYOL イメージを作成して利用する場合はこの限りではありません。

重要：どのボリュームも自動削除(auto-delete)に設定されていないことを確認してください。
重要：ブートボリュームが "general-purpose" ストレージプロファイルを使用していることを確認してください。
このエフェメラル VSI を削除します。これは、VSI を削除してボリュームを作業用VPC VSIにアタッチできる状態にするために必要です。
ボリュームを作業用VPC VSIへアタッチします。複数のボリュームがある場合は、アタッチされる順序に十分注意してください。例えば以下のようにして、ボリュームサイズを調べることができます：
```
blockdev --getsize64 /dev/vdb
```
VMDKをRAWフォーマットに変換し、ブロックデバイスに書き込みます。
```
qemu-img convert -f vmdk -O raw smoonen-ubuntu-1.vmdk /dev/vdb
```
オプション：イメージを変換して、例えばWindows virtio SCSI ドライバーのインストールなどを行いたい場合は、virt-v2v-in-place（または追加コピーを伴う virt-v2v）を使用できます。
パーティションテーブルをスポットチェックします：
```
fdisk -l /dev/vdb
```
なお、ブートディスクをリサイズした場合は、バックアップGPTが適切な位置に書き直されることがあります。
バッファをフラッシュします：
```
blockdev --flushbufs /dev/vdb
```
ボリュームを作業用VPC VSIからデタッチします。
（再び）移行したVM用の新たなVPC VSIを作成します。適切なネットワーク、OS、ディスク構成を設定します。イメージからブートする代わりに、ステップ3で作成しステップ6で書き込んだ既存のブートボリュームからブートします。
- 重要：現在の IBM Cloud UI では、既存のセカンダリボリュームをアタッチすることができません。IBM Cloud CLI や API を使用するか、UI を使う場合は、VSI を停止し、ボリュームをアタッチし、その後再起動する必要があります。
- 重要：SSHキーは実際には使用しなくても、必ず選択する必要があります。
ブートボリュームをリサイズした場合は、パーティションの拡張または追加を行ってください。

方法3: ISO で仮想マシンをブートして VPC ボリュームへコピーする

前述の方法のバリエーションとして、仮想マシンのディスクをエクスポートする代わりに、ISO イメージを用いて VMware VM をブートし、そのディスクを読み取って作業用の VPC VSI に転送し、変換処理を行ったうえで VPC ボリュームへコピーするという方法があります。このアプローチは、かつて使用されていた GHOST ツールから着想を得たものです。

これを行うためには、ソース環境（IBM Cloud Classic でも IBM Cloud VCFaaS でも）と、作業用VPC VSIが存在する宛先VPCを接続するために、IBM Cloud Transit Gateway を作成する必要があるでしょう。これにより、両環境間の直接的なネットワーク接続が可能になります。

上述のやり方の1つは、virt-p2v で作成したブートディスクを使って移行元サーバーを起動し、そこからネットワーク越しに、virt-v2vを実行する作業用VPC VSIへVMware VMのディスクを転送する方法です。

また、TinyCore Linux のような小型の Linux ディストリビューション、あるいは G4L のようなツールを使用して仮想マシンをブートすることもできます。ただし、ディストリビューションが小さければ小さいほど、必要なツールを含めるためにカスタマイズしたり、パブリックリポジトリに接続したりする必要が出てくる可能性があります。（たとえば TinyCore Linux は、デフォルトでは openssh と qemu パッケージが欠落していることがわかりました。）

私の場合は Ubuntu のインストール ISO を持っていたため、それを元の仮想マシンにアタッチしてブートしました。Ubuntu のインストール ISO では、Help ボタンを選択すると「Enter shell」オプションがあり、コマンドを実行できます。

私が採用した方法は、dd コマンドでディスクを読み書きし、gzip でネットワークスループットを改善し、netcat を使ってネットワーク経由で転送するというものです。宛先の作業用VPC VSI側では、以下を実行しました：

nc -l 192.168.100.5 8080 | gunzip | dd of=/dev/vdd bs=16M status=progress
fdisk -l /dev/vdd
blockdev --flushbufs /dev/vdb

（ISOをマウントした）ソース側環境ではネットワーク構成を行い、次のコマンドを実行しました：

# ネットワークデバイス名は BIOS と UEFI などにより異なる場合があります
ip addr add 10.50.200.3/26 dev ens192
ip route add 0.0.0.0/0 via 10.50.200.1
dd if=/dev/sda bs=16M | gzip | nc -N -v 192.168.100.5 8080

ディスク転送後、必要に応じて virt-v2v-in-place や virt-v2v を使用してディスクをさらに変換できます。そして、方法2と同様に、ワーカーVSIからボリュームをデタッチし、それらを実際に使用するVSIを作成する必要があります。

この方法は、効率性（VMDKやOVAのエクスポートは非効率）と柔軟性の両面から、私のお気に入りの方法です。

方法4: VDDK を使用して VPC ボリュームへ直接コピーする

前述のとおり、virt-v2v と VMware VDDK ツールキットを組み合わせて、vCenter と vSphere に接続し、VMware VMのディスクを直接作業用VPC VSIへ読み込むとともに、virtio ドライバーのインストールなどの virt-v2v 処理を実行することが可能です。
ただし、RHEL と Ubuntu の制約が競合しているため手順がかなり複雑であり、現時点では私の推奨方法ではありませんが、動作させることは可能です。
この方法は vCenter へのアクセス権がある場合にのみ利用可能 であり、VCFaaS には適用できません。

この方法を動作させるためには、vCenter および vSphere のホスト名を /etc/hosts に入力する必要がある場合があります。また、仮想マシンが実行されている特定のホストを知っているか、調べる必要があります。

以下はコマンド実行例です。vCenter のパスワードはファイルに指定し、ユーザーIDは domain\user 形式で指定する必要があります。また、vCenter の証明書のサムプリントも確認する必要があります。

virt-v2v -ic vpx://vsphere.local\%5cAdministrator\@smoonen-vc.smoonen.example.com/IBMCloud/cluster1/host000.smoonen.example.com\?no_verify=1 \
  smoonen-win \
  -ip passwd \
  -o disk -os /tmp \
  -it vddk \
  -io vddk-libdir=vmware-vix-disklib-distrib \
  -io vddk-thumbprint=A2:41:6A:FA:81:CA:4B:06:AE:EB:C4:1B:0F:FE:23:22:D0:E8:89:02 \
  --block-driver virtio-scsi

移行後およびその他の考慮事項

上記の手順は、やや手間がかかる作業です。したがって、このプロセスについて慎重に設計し、検証する必要があります。そうすることで、ネットワークやディスクコピーに要する時間に基づいて、どれくらいの処理時間が必要になるかを見積もることも可能になります。また、この手順の一部は自動化できますし、複数のマイグレーションを並行して実行することもできます。

また、この作業を実行する際に支援が必要になる場合もあるかもしれません。そのような場合には、IBM Consulting に相談することができます。IBM Cloud は PrimaryIO や Wanclouds とも提携しており、これらのパートナーからも同様のコンサルティングサービスを受けることができます。

追加リソース

私の同僚のShinobu Yasuda氏が、スクリーンショット付きのステップバイステップ形式の VSI 移行ガイドを執筆しており、vCenter から VPC VSI へさまざまな RHEL および Windows のリリースを正常に移行した手順を紹介しています。

これまで IBM Cloud では、イメージインポート方式のみを推奨するドキュメントが公開されていましたが、最近では、ブートボリュームへの直接移行に焦点を当てた新しいドキュメントも公開されました。これには、VMDK ファイルの移行、VM ディスクのネットワーク経由での直接転送、ならびに VDDK を利用した vCenter への直接接続といった方法が含まれています。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up