Red Hatでソリューションアーキテクトをしている田中司恩(@tnk4on)です。 この連載はvSphere環境上にOpenShift Container Platform（以下、OpenShift）およびOpenShift Virtualizationの環境を構築する方法を解説するシリーズです。
第5回はMigration Toolkit for Virtualization（MTV）を使ったvSphere仮想マシンの移行方法について解説します。
- 第1回：OpenShiftのインストール
- 第2回：OpenShiftインストール後の作業
- 第3回：共有ストレージの作成（NFS CSIドライバーの構築）
- 第4回：OpenShift Virtualizationのインストールと実行
- 第5回：vSphere仮想マシンの移行（←本記事）
- 【番外編】：共有ストレージの作成（NFSプロビジョナーの構築）
-目次-
- vSphere仮想マシンの移行
- 前提条件
- 1. Migration Toolkit for Virtualizationについて
- 2. Migration Toolkit for Virtualizationのインストール
- 3. VDDKイメージの作成
- 4. プロバイダーの作成
- 5. 移行計画の作成
- 6. 移行計画の実行（コールド移行）
- 7. 移行計画の実行（ウォーム移行）
- まとめ
vSphere仮想マシンの移行
本記事ではvSphere仮想マシンの移行について、下記の内容を紹介します。
- Migration Toolkit for Virtualizationについて
- Migration Toolkit for Virtualizationのインストール
- VDDKイメージの作成
- プロバイダーの作成
- 移行計画の作成
- 移行計画の実行（コールド移行）
- 移行計画の実行（ウォーム移行）
前提条件
- 連載第4回の作業を完了していることとします
- 全体の構成や各パラメーターなどは第1回を参照してください
- 作業用端末のプロンプトは
%とします - 踏み台サーバーのプロンプトは
$とします - 踏み台サーバーの作業は明示的に記載がある場合を除いて、作業ディレクトリ
${HOME}/workで作業することとします
1. Migration Toolkit for Virtualizationについて
1-1 移行元プロバイダー
Migration Toolkit for Virtualization（以下、MTV）は、対応している移行元からOpenShift Virtualizationに仮想マシンを移行するツールです。 対応している移行元プロバイダーは下記の通りです。
- VMware vSphere
- Red Hat Virtualization (RHV)
- OpenStack
- VMware vSphere によって作成された Open Virtual Appliances (OVA)
- リモートの OpenShift Virtualization クラスター
MTVが対応しているプロバイダーはドキュメントに記載があります。
第1章 Migration Toolkit for Virtualization について | Red Hat Product Documentation
本記事では一番多いニーズのvSphere（ESXi）からの仮想マシンの移行を対象とし、以後の解説における移行元プロバイダーはVMware vSphereを前提とします。
1-2 移行方式
MTVはコールド移行とウォーム移行の2つの移行方式をサポートしています。
（1）コールド移行
デフォルトの移行方式で、移行元の仮想マシンを停止して移行を行います。 仮想マシンの停止中にデータのコピーを行うので、仮想マシンのサイズが大きい場合はコピーに時間がかかり移行に伴う停止時間が長くなる可能性があります。
（2）ウォーム移行
移行元の仮想マシンを起動した状態でデータのコピーを行います。最終的にカットオーバー処理を行うことで、仮想マシンが停止され残りのデータがコピーされます。 ウォーム移行は移行元がvSphereおよびRHVのみ対応しています。
OpenShift Virtualization v4.16.0-v4.16.2はウォーム移行ができません。 ウォーム移行を行う場合は、必ずOpenShift Virtualization v4.16.3以降にアップデートしてご利用ください。
2. Migration Toolkit for Virtualizationのインストール
2-1 インストールの概要
MTVのインストールは、第4回で実施したOpenShift Virtualizationのインストールと同様に、Operatorを使って行います。 Operatorを使ったMTVのインストールの流れは下記の通りです。
- Operatorのインストール
- ForkliftControllerの作成
2-2 インストールの前提条件
MTVをインストールするには対応するOpenShiftおよびOpenShift Virtualizationがインストールされている必要があります。
2-3 Operatorのインストール
MTVのインストール作業を行います。対象のドキュメントは下記を参照してください。
OpenShiftのWebコンソールから「Operator>Operator Hub」メニューを選択します。
キーワードの入力欄にopenshift virtと入力するとフィルタリングされて「OpenShift Virtualization」と「Migration Toolkit for Virtualization Operator」の2つが表示されます。
「Migration Toolkit for Virtualization Operator」を選択します。
チャネルとバージョンはデフォルト表示のままで「インストール」を押します。
インストールの詳細入力画面が開きます。ここでもデフォルト表示のままインストールを押します。 なお、（FC）ForkliftControllerが必須となっていますが、これは後ほどインストールするのでそのまま無視します。
- 更新チャネル：release-v2.6（releaseバージョン以外にcandidateがある）
- バージョン：2.6.7（本記事執筆時点では「2.6.7」が最新）
- インストールモード：クラスターの特定のnamespace
- インストール済みのnamespace：Operator推奨のnamespace:openshift-mtv
- 更新の承認：自動
Migration Toolkit for Virtualization Operatorのインストールが開始します。環境にもよりますが、インストールの完了まで1分程度かかります。インストールの完了までそのままでお待ちください。なお、インストール自体はバックグラウンドで継続されるため、他の画面に遷移しても問題ありません。
インストールが完了すると「ForkliftControllerの作成」ボタンが表示されます。これを押して次のステップに進みます。
2-4 ForkliftControllerの作成
先のステップで「ForkliftControllerの作成」ボタンを押すと、「ForkliftControllerの作成画面」が表示されます。 そのまま「作成」ボタンを押します。
この「ForkliftControllerの作成画面」は、Webコンソールのメニューから「Operator>インストール済みのOperator>Migration Toolkit for Virtualization Operator」を選択して表示される画面上の、「ForkliftControllerの作成」ボタンを押した後に出る画面と同じものです。別の画面に遷移した場合はここから作業を継続してください。
「作成」ボタンを押した後は自動で「インストール済みのOperator>Operatorの詳細画面」から、ForkliftControllerのタブが選択された状態の画面に遷移します。
インストールが進むにつれステータスの表示が変わります。ここも環境によりますが、完了まで2-3分ほどかかりますのでまでそのまま待機します。
インストールの完了後、画面上部にポップアップ画面が表示されます（ステータス表示が変わる前に表示されることもあります）。ポップアップ画面内の「Webコンソールの更新」のリンクを押す、またはブラウザをリロードします。
画面の更新後、Webコンソールのメニュー内に「Migration」の項目が追加されています。
Webコンソールのメニューから「Migration>Overview」を選択します。
以上でMigration Toolkit for Virtualizationのインストールは完了です。 続けてvSphere/ESXiの仮想マシンの移行に使用するVDDKイメージの作成を行います。
3. VDDKイメージの作成
VMware Virtual Disk Development Kit (以下、VDDK) はVMwareの仮想ディスクにアクセスしたり作成するためのSDKです。MTVはVDDKを使用しvSphere仮想マシンの転送を高速化します。 なお、VDDKの利用は任意ですが利用することは強く推奨します（ほぼ必須）。 ここではVDDKを組み込んだコンテナイメージ（VDDKイメージ）を作成し、MTVから利用できるようにします。
VDDKの入手先はBroadcom社によるVMware社の買収後は、Broadcom社のサイトで配布が行われています。
VDDKはWindowsおよびLinux向けのSDKが配布されており、「VMware Software Development Kit License Agreement」への合意に基づき利用が可能です。 なお、VDDKをダウンロードするにはBroadcomのアカウントでログインする必要があります。 事前にLinux版のVDDKを入手し、作業用端末に保存しておいてください。最新版はv8.0.3です（記事執筆時点）。
3-1 VDDKイメージの作成手順
VDDKイメージの作成手順は下記のドキュメントを基に行います。
VDDKイメージの注意点は「パブリックの領域に保存しない」ことです。ライセンスで再配布が禁止されているためです。 本記事では、OpenShiftの内部イメージレジストリにVDDKイメージを保存するようにします。
（1）VDDKイメージのビルド
踏み台サーバーでVDDKイメージの作成用の作業ディレクトリを作成し、そこへ移動します。
$ mkdir VDDK $ cd VDDK
VDDKを作業用端末から、踏み台サーバー上の作業用ディレクトリにコピーします。 なお、入手したVDDKが作業用端末のカレントディレクトリにあることとします。
（作業用端末で実行） % scp VMware-vix-disklib-8.0.3-23950268.x86_64.tar.gz bastion:work/VDDK
踏み台サーバーでVDDKを解凍します。
$ ls -d VMware-vix-disklib-8.0.3-23950268.x86_64.tar.gz VMware-vix-disklib-8.0.3-23950268.x86_64.tar.gz $ tar xzf VMware-vix-disklib-8.0.3-23950268.x86_64.tar.gz $ ls -d vmware-vix-disklib-distrib vmware-vix-disklib-distrib
VDDKイメージのDockerfileを作成します。*1
$ cat > Dockerfile <<EOF FROM registry.access.redhat.com/ubi8/ubi-minimal USER 1001 COPY vmware-vix-disklib-distrib /vmware-vix-disklib-distrib RUN mkdir -p /opt ENTRYPOINT ["cp", "-r", "/vmware-vix-disklib-distrib", "/opt"] EOF
ビルドするタグ名を取得するためにOpenShiftクラスタへログインします。
ocpadminユーザーでログインするためにKUBECONFIG環境変数を解除します。
詳細は連載第2回を参照。
$ unset KUBECONFIG $ oc login -u ocpadmin https://api.ocp.home.lab:6443 WARNING: Using insecure TLS client config. Setting this option is not supported! Console URL: https://api.ocp.home.lab:6443/console Authentication required for https://api.ocp.home.lab:6443 (openshift) Username: ocpadmin Password:
パスワードを入力してOpenShiftにログインできたことを確認します。
Login successful. You have access to 74 projects, the list has been suppressed. You can list all projects with 'oc projects' Using project "ocp-virt".
イメージレジストリのURLを取得しHOST環境変数へセットします。
詳細は連載第3回を参照。
$ HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')
$ echo ${HOST}
default-route-openshift-image-registry.apps.ocp.home.lab
取得したHOST環境変数をタグ名に使用し、VDDKイメージをビルドします。
実行コマンド
$ podman build -t ${HOST}/openshift/vddk .
実行コマンドと結果
$ podman build -t ${HOST}/openshift/vddk .
STEP 1/5: FROM registry.access.redhat.com/ubi8/ubi-minimal
Trying to pull registry.access.redhat.com/ubi8/ubi-minimal:latest...
Getting image source signatures
Checking if image destination supports signatures
Copying blob 76e9cdf18aba done |
Copying config 7aaf580966 done |
Writing manifest to image destination
Storing signatures
STEP 2/5: USER 1001
--> 9690c68eb273
STEP 3/5: COPY vmware-vix-disklib-distrib /vmware-vix-disklib-distrib
--> e6bd091b0d6a
STEP 4/5: RUN mkdir -p /opt
--> cc8588d591eb
STEP 5/5: ENTRYPOINT ["cp", "-r", "/vmware-vix-disklib-distrib", "/opt"]
COMMIT default-route-openshift-image-registry.apps.ocp.home.lab/openshift/vddk
--> 7da3e1ed5e31
Successfully tagged default-route-openshift-image-registry.apps.ocp.home.lab/openshift/vddk:latest
7da3e1ed5e3158a4a685609285f67ab18bf86721617e0305fd5e9fdee1eafbd0
（2）VDDKイメージのプッシュ
OpenShiftのログイン情報とHOST環境変数を利用して、podman loginコマンドでイメージレジストリへログインします。
$ podman login -u ocpadmin -p $(oc whoami -t) ${HOST}
Login Succeeded!
続けて、VDDKイメージのプッシュを行います。
実行コマンド
$ podman push ${HOST}/openshift/vddk
実行コマンドと結果
$ podman push ${HOST}/openshift/vddk
Getting image source signatures
Copying blob 67be5b5d64dc done |
Copying blob 405af4f177b1 done |
Copying blob bae4fda36bb4 done |
Copying config 7da3e1ed5e done |
Writing manifest to image destination
確認コマンド
$ skopeo inspect docker://${HOST}/openshift/vddk
Skopeoを使ってプッシュしたコンテナイメージがイメージレジストリーに登録されているか確認します。
確認コマンドと結果
出力結果を開く
$ skopeo inspect docker://${HOST}/openshift/vddk
{
"Name": "default-route-openshift-image-registry.apps.ocp.home.lab/openshift/vddk",
"Digest": "sha256:e37ebbedc80cb490fa7909cae202301fbe8e604a712354db5054a0a002ea58e1",
"RepoTags": [
"latest"
],
"Created": "2024-07-30T06:52:39.356472214Z",
"DockerVersion": "",
"Labels": {
"architecture": "x86_64",
"build-date": "2024-06-27T11:18:10",
"com.redhat.component": "ubi8-minimal-container",
"com.redhat.license_terms": "https://www.redhat.com/en/about/red-hat-end-user-license-agreements#UBI",
"description": "The Universal Base Image Minimal is a stripped down image that uses microdnf as a package manager. This base image is freely redistributable, but Red Hat only supports Red Hat technologies through subscriptions for Red Hat products. This image is maintained by Red Hat and updated regularly.",
"distribution-scope": "public",
"io.buildah.version": "1.33.7",
"io.k8s.description": "The Universal Base Image Minimal is a stripped down image that uses microdnf as a package manager. This base image is freely redistributable, but Red Hat only supports Red Hat technologies through subscriptions for Red Hat products. This image is maintained by Red Hat and updated regularly.",
"io.k8s.display-name": "Red Hat Universal Base Image 8 Minimal",
"io.openshift.expose-services": "",
"io.openshift.tags": "minimal rhel8",
"maintainer": "Red Hat, Inc.",
"name": "ubi8-minimal",
"release": "1018",
"summary": "Provides the latest release of the minimal Red Hat Universal Base Image 8.",
"url": "https://access.redhat.com/containers/#/registry.access.redhat.com/ubi8-minimal/images/8.10-1018",
"vcs-ref": "4f8da2b64a13f2a264bd802d8909bf803211fb20",
"vcs-type": "git",
"vendor": "Red Hat, Inc.",
"version": "8.10"
},
"Architecture": "amd64",
"Os": "linux",
"Layers": [
"sha256:76e9cdf18aba09dd872666d609fbdc8cd5c6c418c119dc113872061ba434b70f",
"sha256:f83fb1808400a57a0096f736d9b38e7e4f7ee405a2bb968702c3402d5286019d",
"sha256:6c7b8478d4963d8b248ed45d3496c02cab837c540eafe989e6107454846c7571"
],
"LayersData": [
{
"MIMEType": "application/vnd.oci.image.layer.v1.tar+gzip",
"Digest": "sha256:76e9cdf18aba09dd872666d609fbdc8cd5c6c418c119dc113872061ba434b70f",
"Size": 39346374,
"Annotations": null
},
{
"MIMEType": "application/vnd.oci.image.layer.v1.tar+gzip",
"Digest": "sha256:f83fb1808400a57a0096f736d9b38e7e4f7ee405a2bb968702c3402d5286019d",
"Size": 44400224,
"Annotations": null
},
{
"MIMEType": "application/vnd.oci.image.layer.v1.tar+gzip",
"Digest": "sha256:6c7b8478d4963d8b248ed45d3496c02cab837c540eafe989e6107454846c7571",
"Size": 226,
"Annotations": null
}
],
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"container=oci"
]
}
VDDKイメージの作成が完了しました。次は移行元プロバイダーの作成を行います。
4. プロバイダーの作成
MTVは移行元プロバイダーとしてVMware vSphereに対応していますが、実際にはvCenter ServerまたはESXiを指定して登録を行います。 本連載はでESXiを移行元プロバイダーとして指定します。
Webコンソールのメニューから「Migration>Providers for virtualization」を選択します。 プロジェクトを「すべてのプロジェクト」を選択すると、「host」プロバイダーが登録されているのが確認できます。 これはMTVのインストール時に自動で登録されたもので、Typeが「OpenShift」となっており、OpenShift Virutalizationそのものを指す設定とご理解ください。
新しくプロバイダーを追加するには「Create Provider」ボタンを押します。
「Provider details」では、登録可能なプロバイダーの一覧が表示されます。この中から「vSphere」を選択します。
選択したプロバイダーの詳細な設定入力画面に遷移します。ここでプロバイダー登録に必要な情報を入力します。
Provider details
- Select provider type: vSphere
- Provider resource name: esxi（任意の名前）
- Endpoint type：ESXi
- URL: https://esxi.home.lab/sdk
- VDDK init image: image-registry.openshift-image-registry.svc:5000/openshift/vddk:latest
Provider credentials
- Username: root
- Password:（ESXiのrootのパスワード）
- Skip certificate validation: true
パラメーターの入力後、「Create provider」ボタンを押します。
プロバイダーの登録後、登録したプロバイダーの詳細画面に遷移します。
Webコンソールのメニューから「Migration>Providers for virtualization」を再度選択すると、先ほど登録したプロバイダーが一覧に追加されたことが確認できます。
次は登録したプロバイダーを使って、移行契約の作成を行います。
ESXiホストがFQDNで登録されていない場合
ESXiホスト自身にFQDNの設定が行われていない場合、MTVの移行時でエラーになる場合があります。 FQDNの設定が行われていない場合はESXi ShellまたはESXiホストへSSH接続を行い、下記の設定を行います。
実行コマンド
（ESXiホスト上で実行） [root@esxi:~] hostname -f esxi [root@esxi:~] esxcli system hostname set --fqdn=esxi.home.lab [root@esxi:~] hostname -f esxi.home.lab
FQDN設定後、再度プロバイダーを登録してます。「Providers>Provider Details」から「Hosts」タブを選択し、ESXiホストがFQDNで登録されていることを確認します。
5. 移行計画の作成
MTVは移行計画の作成を行なって仮想マシンの移行を行います。移行計画には1つ以上の仮想マシンを含めることができます。
5-1 プロバイダーの選択
Webコンソールのメニューから「Migration>Plans for virtualization」を選択します。 プロジェクトから「すべてのプロジェクト」を選択します。移行計画がまだ作成されていないことを確認し、「Create Plan」ボタンを押します。
「Select source provider」から作成したプロバイダー：esxiを選択すると、ESXiホストマシン上の仮想マシンが一覧で表示されます。
一覧から移行したい仮想マシンにチェックを入れ、「Next」ボタンを押します。 ここでは「rhel9-vmware」を選択します。
5-2 移行計画の作成
次の画面では移行計画の作成に必要な情報を入力します。
Create migration plan
- Plan name: migration-01
- Source provider: 移行元のプロバイダー。「esxi」が選択済み。
- Target provider: 移行先のプロバイダー。デフォルトの「host」が選択済み。
- Target namespace: 移行先のNamespaceを指定可能。ここでは「ocp-virt」を選択。
- Network map:
- VM Network（移行元のVMの仮想スイッチ）: Pod Networking（移行先のNAD）
- Storage map:
- NVMe（移行元のVMの保存ストレージ）: nfs-client（移行先のストレージクラス）
すべての項目を入力後、「Create migration plan」ボタンを押します。
StatusがReadyになるまでそのまま待機します。初回は使用するコンテナイメージのダウンロードや展開に時間を要するため、3分ほどかかります。
Webコンソールのメニューから「Migration>Plans for virtualization」を再度選択し、作成した移行計画が一覧に登録されていることを確認します。
StatusにWarningが出る場合：
移行元の仮想マシン名（インベントリに登録している名前）に大文字が含まれている場合、StatusがWarningになります。
Warning Target VM name does not comply with DNS1123 RFC, will be automatically changed. To troubleshoot, view the plan details page and check the Forklift controller pod logs.
- 例）RHEL、など
そのまま移行を行うと、移行時に自動で小文字に変換されます。 なお、StatusがWarningであっても、「Start migration」ボタンが押せる状態であれば移行は可能です。
6. 移行計画の実行（コールド移行）
6-1 コールド移行の実行
作成した移行計画はデフォルトでは「コールド移行」となります。そのままコールド移行を行う場合は「Start migration」ボタンを押します。移行計画の一覧画面から実行する場合は「Start」ボタンを押します。
どちらの場合も実行の確認画面が表示されるので、「Start」ボタンを押します。
StatusがRunningに変わり、移行が開始されます。なお、起動中の仮想マシンはこの時点で停止します。
6-2 移行の進捗確認
移行中の進捗確認は、移行計画の詳細画面から「Virtual Machines」タブを選択します。 さらに、「>」を展開し、Pipelineで進捗状況を確認できます。
Pipelineには下記の段階ごとに進捗状況が更新されます。
- Initialize（Initialize migration）
- DiskAllocation（Allocate disks）
- ImageConversion（Convert image to kubevirt）
- DiskTransferV2v（Copy disks）
- VirtualMachineCreation（Create VM）
最後の「VirtualMachineCreation」が完了すると、Webコンソールのメニュー「Virtualization>VirtualMachines」の仮想マシン一覧に移行した仮想マシンが登録されます。
6-3 移行した仮想マシンの起動テスト
移行が完了すると自動で移行した仮想マシンは起動します。 移行後の仮想マシンはOpenShift Virtualizationで作成した仮想マシンと同様に操作できます（起動、停止、コンソール、スナップショット、ライブマイグレーション、など）。
7. 移行計画の実行（ウォーム移行）
7-1 ウォーム移行の前提条件
ウォーム移行を行う場合、対象の仮想マシンにChanged Block Tracking (以下、CBT)の設定を行う必要があります。 仮想マシンにCBTの設定を行う方法は、下記のドキュメントを参照ください。
govcコマンドを使用してCBTを有効化するには下記の手順を実行します。
なお、対象の仮想マシン（win2022-vmware）は事前にシャットダウンしていることとします。
実行コマンド
$ govc vm.change -vm win2022-vmware -e="ctkEnabled=true"
CBTの設定状況は下記のコマンドで確認します。
実行コマンド
$ govc vm.info -e ctkEnabled=true win2022-vmware | grep ctkEnabled
ctkEnabled: TRUE
7-2 ウォーム移行の設定
ウォーム移行を行う場合もコールド移行と同じ手順で移行計画を作成します。 ここでは「migration-02」として、「win2022-vmware」仮想マシンのウォーム移行を行います。 本記事「5. 移行計画の作成」の手順を参考に、移行計画を作成してください。
ウォーム移行を行う場合は、移行計画の作成後にコールド移行からウォーム移行へと設定を変更します。 移行計画の詳細画面から、「Settings>Warm migration」内の編集ボタンを押します。
「Set warm migration」の設定画面がポップアップ表示されます。 ウォーム移行の設定を有効化し、「Save」ボタンを押します。
7-3 ウォーム移行の実行
コールド移行と同様に、移行計画の詳細画面から「Start migration」ボタンを押してウォーム移行を実行します。
コールド移行と同様に、実行の確認画面が表示されるので、「Start」ボタンを押します。
7-4 移行の進捗確認
移行中の進捗確認は、コールド移行と同様に移行計画の詳細画面から「Virtual Machines」タブを選択します。
コールド移行と異なるのは、ウォーム移行では最初の移行の実行後に初期転送が行われ、カットオーバーが行われるまで進捗はその状態のままになることです。
ウォーム移行の開始後、移行元の仮想マシンに「forklift-migration-precopy」という名前のスナップショットが作成されます。 デフォルトでは「60分ごと」に差分の更新が行われ、その際に新しいスナップショットが作成されて、古いスナップショットは削除されます。 その後、カットオーバーを行うまで更新は自動で継続されます。
プレコピーの更新間隔の変更
プレコピーの更新間隔はMTVのOverview画面で変更が可能です。 Webコンソールのメニューから「Migration>Overview」を選択し、「Settings」内の「Precopy interval (minutes)」の値を変更します。 変更できる値は「5分、30分、60分、120分」から選択する方式です。
※注意：更新間隔を5分に設定しても、前後の処理時間が追加されるため、次回のスナップショットの作成時間は5分より超えて行われます
7-3 カットオーバーの実行
プレコピーの実行後、カットオーバーを実行することで最終のデータコピーが行われ、仮想マシンの移行が完了します。
移行計画の詳細画面から「Actions>Cutover」を選択することでカットオーバーを開始します。 または、移行計画の一覧画面から実行する場合は、対象の移行計画の「Cutover」ボタンを押します。
カットオーバーのスケジュール設定画面がポップアップで表示されます。指定の時間にカットオーバーを行う場合は日時を選択して「Set cutover」を押します。 すぐにカットオーバーを行いたい場合は、そのまま「Set cutover」を押します。
カットオーバーを実行すると、移行元の仮想マシンがシャットダウンされ、最終のデータコピー（ファイナライズ）が実行されます。
その後、イメージ変換のプロセスを経て仮想マシンが作成されます。
※注意：初回のウォーム移行実行時は、イメージ変換に使用するコンテナイメージのダウンロード、解凍に時間を要する場合があります。
コールド移行と同様に、移行完了後の仮想マシンは自動で起動します。
まとめ
MTVを使用したvSphere仮想マシンの移行方法について解説しました。 今回はシンプルな検証環境での実行を前提としたのでESXiを移行元プロバイダーとして使用しました。 実稼働環境ではvCenter Serverを使用することがほとんどですが、設定方法や移行の方法は同じですので、実稼働環境（およびその検証環境）でも同じ手順で移行の実行を行ってください。 本連載では対象の範囲外とした複雑なネットワークやストレージ環境においても、移行のマッピングを適切に行うことで移行は可能です。 是非さまざまな環境で移行の実行を行ってみてください。
本連載はこの記事をもって終了となりますが、書ききれなかった内容は多々あります。 それらについてはまた別の記事で補足することとします。
*1:ドキュメントでDockerfileとなっているため、ここではContainerfileとせずそのまま記載
