vCenter Converter で EC2 インスタンスを VMware Cloud on AWS に移行する（VTGW編）

# はじめに
vCenter Converter は、VMware が提供する、ワークロードを VMware 仮想化基盤に移行するためのツールです。

以前 vCenter Converter を使って Connected VPC 上の Amazon EC2 インスタンスタンスを VMware Cloud on AWS に移行する方法を[投稿](https://qiita.com/mtoyoda/items/a2a0c96196c58d86e14a)しました。

https://qiita.com/mtoyoda/items/a2a0c96196c58d86e14a

今回は、vCenter Converter を使って移行するもう一つのパターンである、VTGW 経由での接続パターンを試してみたいと思います！

前回の投稿と重複する部分は省きつつ、差分をメインで記載してみようと思います。


# 改めて vCetner Converter とは
vCenter Converter は、VMware が提供する、ワークロードを VMware 仮想化基盤に移行するためのツールです。

vCenter Converter は主に以下の機能を提供します：
- P2V（Physical-to-Virtual）変換：物理マシンを仮想マシンに変換します。この変換により、ハードウェアの依存性を排除し、物理サーバーの管理コストを削減できます。
- V2V（Virtual-to-Virtual）変換：異なるホスト上の仮想マシンを vSphere 環境に移行します。

<img src="https://www.vmware.com/content/dam/digitalmarketing/vmware/en/images/products/converter/vmware-converter.jpg" width="600" />

*図は [vCenter Converter のページ](https://www.vmware.com/jp/products/converter.html)からの抜粋*


2023 年 4 月に vCenter Converter 6.4 が[発表](https://blogs.vmware.com/code/2023/04/19/vcenter-converter-6-4-beta-is-available/)され、EC2 からの移行がサポートされるようになりました。

# VTGW とは
VTGW とは、VMware Transit Connect サービスにおける、**VMware マネージドの AWS Transit Gateway** の総称です。

<img src="https://blogs.vmware.com/vmware-japan/files/2020/11/%E5%9B%B31-1024x462.png" width="600" />

*図は [VMware Japan Blog: VMware Transit Connect – VMware Cloud on AWS のためのシンプルかつ柔軟なネットワーク構成](https://blogs.vmware.com/vmware-japan/2020/11/vmware-transit-connect.html)からの抜粋*

VMware Cloud on AWS と Amazon VPC との接続パターンについては、以下の投稿を参照下さい。

https://qiita.com/mtoyoda/items/99c9b5af4392fdc3c170


# 今回の構成

以下のような構成で移行を試してみます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/8edbeb5e-5308-e89e-7cc0-022ae1b6d3d6.png)

- vCenter Converter は VMware Cloud on AWS 上の Windows VM (Windows Server 2019) にインストール
- 移行対象の EC2 インスタンスは、VTGW 経由で接続された 外部 VPC 上にデプロイ。以下の２つのインスタンスを対象としました:
    - **Ubuntu 16.04 LTS**  ※前回 Connected VPC 経由ではうまくいかなかった インスタンス
    - Windows Server 2019

# 外部 VPC との接続 （VTGW）

外部 VPC と接続をする為に SDDC グループ（VTGW）の構成を行います。
以下のスクリーンショットのように 外部 VPC の接続を行いました。外部 VPC で利用している 172.31.0.0/16 をスタティックルートとして追加をしています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/a2c81839-8ef8-956c-7d35-fef24d1194c2.png)

外部 VPC （AWSアカウント側）のルートテーブルの設定も行います。

| 送信先                                                                                                                                                         | ターゲット |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------- | ----- |
| 1. SDDC 管理サブネット <br> 2. vCenter Converter <br> 3. 移行先の論理ネットワークのセグメント <br> 4. 送信元 NAT のパブリック IP<br> ※ 送信元 NAT のパブリック IP は [ネットワークとセキュリティ] タブの [概要] から確認できます。 | Transit Gateway アタッチメント      |

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/6d450715-769b-fa18-7fa4-7ab2be1f9757.png)

:::note info
今回は、10.2.0.0/16 が SDDC 管理サブネット、192.168.2.0/24 が vCenter Converter 及び 移行先の論理ネットワークのセグメントとして利用しています。
:::

VTGW の構成については、以下のブログを参照下さい。

https://dev.classmethod.jp/articles/vmware-cloud-on-aws-sddc-group/

# vCenter Converter のインストール・構成

vCenter Converter のインストールと構成は [Connected VPC の際](https://qiita.com/mtoyoda/items/a2a0c96196c58d86e14a#vcenter-converter-%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB)と違いはありません。

# ゲートウェイ ファイアウォール、セキュリティグループのルール追加

ゲートウェイ ファイアウォールのルール、及びセキュリティグループも[前回](https://qiita.com/mtoyoda/items/a2a0c96196c58d86e14a#%E3%82%B2%E3%83%BC%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A4-%E3%83%95%E3%82%A1%E3%82%A4%E3%82%A2%E3%82%A6%E3%82%A9%E3%83%BC%E3%83%AB%E3%81%AE%E3%83%AB%E3%83%BC%E3%83%AB%E8%BF%BD%E5%8A%A0)と違いはありません。
しかしながら、検証をしていく中で Linux の移行をするにはドキュメントに載ってないルールも必要である事がわかりました・・・
**太字**で記載した部分が今回検証して追加で必要と分かった部分です。


1. グループの作成
    以下のグループを作成します。

    | 追加先グループ           | 名前                       | メンバー                                                          |
    | ----------------- | ------------------------ | ------------------------------------------------------------- |
    | 管理グループ            | Converter Server         | 1. Converter Server のプライベート IP アドレス <br> 2. 送信元 NAT のパブリック IP |
    | 管理グループ            | EC2-Subnets              | Connnected VPC のサブネット                                         |
    | コンピューティンググループ     | Converter Server         | Converter Server の VM                                         |
    | **コンピューティンググループ** | **Converted VM network** | **移行先の論理ネットワークのセグメント**（今回の場合、192.168.2.0/24）                   |

    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/51dc18a1-7dd5-c2be-8a7b-b4ad31e99ea9.png" width="500" />



1. 管理ゲートウェイのファイアウォールルールの作成
    [前回](https://qiita.com/mtoyoda/items/a2a0c96196c58d86e14a#%E3%82%B2%E3%83%BC%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A4-%E3%83%95%E3%82%A1%E3%82%A4%E3%82%A2%E3%82%A6%E3%82%A9%E3%83%BC%E3%83%AB%E3%81%AE%E3%83%AB%E3%83%BC%E3%83%AB%E8%BF%BD%E5%8A%A0)と違いはありません。

1. コンピュート ゲートウェイのファイアウォールルールの作成
    以下のルールを作成します。

    | 送信元              | 宛先  | サービス | アクション |
    | ---------------- | --- | ---- | ----- |
    | Converter Server <br>**Converted VM network** | Any | Any  | Allow |


    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/451a9730-0a9a-1b89-899e-8f25fdd99d97.png)

1. セキュリティグループの追加（AWS アカウント側）
    [前回](https://qiita.com/mtoyoda/items/a2a0c96196c58d86e14a#%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97%E3%81%AE%E8%A8%AD%E5%AE%9A)と違いはありません。


# 移行対象の EC2 インスタンスの準備

今回は 以下 2つの インスタンスを移行してみます。

1. Windows Server 2019
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/c00ea3ef-debf-426e-999c-50c5e677738b.png)

1. **Ubuntu 16.04 LTS** 
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/87f5cb39-14d8-aa18-4e32-b287e2d9b657.png)


# vCenter Converter で移行をしてみる

準備が整いましたので、vCenter Converter で EC2 インスタンスを VMware Cloud on AWS へ移行してみます。

## Windows Server 2019

1. VMware Cloud on AWS の vCenter の情報を入力するところで [Use proxy mode] にチェックを**入れない**で次に進みます。（Connected VPC の際は Proxy mode のチェックが必要です）
    
1. 今回も20分程度で完了しました。
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/0f54c743-ea76-083f-121f-379e04400323.png)

## Ubuntu 16.04 LTS
1. vCenter Converter 用の Windows VM にログインし、vCenter Converter Standalone Clientを起動します。
1. “Convert machine” をクリックします。
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/59c1b3b8-71ed-ff7b-bff2-d1a2781e4572.png" width="400" />
1. 以下の通り EC2 インスタンスの情報を入力しました。 IP アドレスは EC2 インスタンスのプライベート IP アドレスを入力しています。
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/e8c805b0-dd73-7a05-a310-d6c3c8ad399f.png" width="400" />
1. VMware Cloud on AWS の vCenter の情報を入力します。
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/2bb24c4a-19ad-47a6-ca9c-4f5c959a0e70.png" width="600" />
1. 次に移行先のフォルダを指定します。必要に応じて仮想マシン名も変更します。
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/eaded2ce-eea4-1f9c-9d98-b855e57e1e07.png" width="550" />
1. 移行先のリソースプールとデータストアを指定します。データストアについてはデフォルトで vsanDatastore が選択されており、変更しないとエラーになるので注意下さい。
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/3d5c5d44-a220-c999-ab1c-3d108acedbc0.png" width="550" />
1. 必要に応じて設定を編集します。（移行先のネットワークなどを変更します）
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/5d8dd035-f968-1b49-2c06-12b7b9bcc7d3.png" width="550" />
1. 設定内容を確認し、Finish をクリックします。
1. ゲートウェイファイアウォールのドキュメントに載っていないルールの追加に辿り着くまでにトライアンドエラーを繰り返した後に、ついに移行が完了しました。Ubuntu については 3分ほどで完了しました。
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/4fc0cbf6-0bc3-5959-c00d-c89c509cfc84.png)
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/54568570-6837-7331-6356-954a05d54905.png" width="650" />


# Connected VPC でも Linux の EC2 インスタンスの移行成功！

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/649fae33-e8ea-03d3-591f-f5567c1f88c9.png)

前回、[Connected VPC では Linux の EC2 インスタンスは移行できない？？](https://qiita.com/mtoyoda/items/a2a0c96196c58d86e14a#connected-vpc-%E3%81%A7%E3%81%AF-linux-%E3%81%AE-ec2-%E3%82%A4%E3%83%B3%E3%82%B9%E3%82%BF%E3%83%B3%E3%82%B9%E3%81%AF%E7%A7%BB%E8%A1%8C%E3%81%A7%E3%81%8D%E3%81%AA%E3%81%84)とコメントさせて頂きました。
しかしながら今回の検証を進めていく上でゲートウェイファイアウォールの、ドキュメントされていないルールを追加する事で対応が可能な事がわかりました・・・

改めて検証したところ Connected VPC でも Linux インスタンスの移行は可能でした！VTGW の場合と同様に 3分ほどで移行が完了しました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/2d775969-a2c1-f37d-09d9-42c678eac2bf.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/30b5c313-31a6-2e15-bb75-cd358a4e7539.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/ee3c42fa-890d-3bd7-7b25-2ded9036616f.png)

# Connected VPC と VTGW におけるパフォーマンスの違い
VMware Cloud Tech Zone の [Designlet: Migrating AWS EC2 Instances into VMware Cloud on AWS using vCenter Converter 6.4](https://vmc.techzone.vmware.com/resource/designlet-migrating-aws-ec2-instances-vmware-cloud-aws-using-vcenter-converter-64#introduction) によると、VTGW 経由の方が Connected VPC よりも移行のパフォーマンスが良いという事でしたが今回の検証では、双方の移行パターンにおけるパフォーマンスの差は見られませんでした。大規模環境においては違いが出てくるかもしれませんが、小規模や検証環境においては、特に気にするほどではないかもしれません。

# 最後に
前回の経験を踏まえて今回はすんなりと検証が終わるかと思いましたが、今回もハマりました・・・
エラーになった際、詳細ログを確認しても詳しいエラーが記載されておらず、原因の追及が難しくトライアンドエラーでの検証が必要でした。
エラーになった時に、エラーメッセージをわかりやすく出力してくれるか、もう少し対応方法についてのガイドが整備されるとありがたいです！
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/3e849c43-0842-b8fc-7da2-fafedfb80301.png)

色々とハマった結果を本稿にまとめたので、今後 vCenter Converter で EC2 インスタンスの移行を検討される方の参考になれば幸いです。
最後までご覧いただきまして、ありがとうございました。


# 参考文献
VMware Cloud Tech Zone - Designlet: Migrating AWS EC2 Instances into VMware Cloud on AWS using vCenter Converter 6.4

https://vmc.techzone.vmware.com/resource/designlet-migrating-aws-ec2-instances-vmware-cloud-aws-using-vcenter-converter-64

# 関連記事

https://qiita.com/mtoyoda/items/a2a0c96196c58d86e14a