1. はじめに

とうとうVMware Cloud on AWS M7iインスタンスが提供開始されたということで、デプロイしてみました。
仮想マシンの作成、HCXのデプロイ、FSxNの別SDDCへの付け替えなども追加で試してみました。

VMware Cloud on AWS M7i インスタンスをデプロイしたので、コンソールから見えてきた様子などを備忘録として残します。

本記事の内容は、2024 年 3 月時点での公開情報および個人的なハンズオンの結果をベースにしています。
最新情報については Broadcom 社公式サイトをご確認お願いします。

なお、本記事は前回紹介した内容の追加となります。

2. VMware Cloud on AWS M7i インスタンスをデプロイしてみる

SDDC初期デプロイ

M7i-24xl (DISKLESS)」を2ホスト構成でデプロイすると、初期状態は次のようになります。
M7iインスタンスはディスクレスタイプなので、この時点ではユーザーが利用できるストレージ容量はありません。

(※)ESXiブート領域とマネジメントデータストアは別途サービス側で準備されていますがこの画面上では確認できません。

vCenterから確認

vCenterにログインし、SDDCのデフォルト状態を確認します。

ESXiホストのモデルも「Amazon EC2 m7i.metal-24xl」となっていることが確認できます。

管理系VMのデータストア(managementDatastore)も確認してみます。
よくみるとAmazon FSx for NetApp ONTAP (FSxN)が利用されていることがわかります。

vCenterやNSXなど、管理系VMが格納されています。

3. FSxNのNFSデータストアマウント後

VMware Cloud コンソールから確認

作成したVMware Cloud on AWSからFSxN(1TB)をNFSデータストアマウントしてみました。

Storage容量が反映されています。

仮想マシンをデプロイしてみる

手持ちのOVFファイルをアップロードして、仮想マシンをいくつかデプロイしました。

デプロイ対象のストレージは当然FSxNを選択します。

仮想マシンを確認すると、ディスク領域としてFSxNが選択されているのが確認できます。

データストアからも、作成した仮想マシンを確認できます。

4. FSxNデタッチ & VPC Peeringの接続解除

今回は一時的な検証環境だったのでSDDCを削除する必要がありました。
一旦FSxNデタッチし、VPC Peeringを接続解除してからSDDCを削除します。その後、別のSDDCからFSxNを再度NFSデータストアマウントします。

NFSデータストアのデタッチ

まずはNFSデータストアとして利用しているFSxNをデタッチします。

サクサク進む、と思いきや早速エラーが出ました。
仮想マシンがNFSデータストアに登録されているため、デタッチができないとのこと。

FSxNをデータストアとして利用している仮想マシンを、「Remoce from Inventory」を実行してインベントリーから登録解除します。

同じ作業を繰り返し、FSxNをデータストアとして利用している仮想マシンをすべてインベントリーから登録解除しました。

もちろんデータ自体は削除していないので、仮想マシンイメージはFSxNに残り続けています。(#5で再利用します)

そして再度、NFSデータストアをデタッチします。

今度こそ処理が進み、1-2分ほどでNFSデータストアのデタッチが完了しました。

VPC Peeringの接続解除 (VMware Cloudコンソール側作業)

次は、VPC Peeringの接続を解除します。

対象のVPC Peeringを選択し、「DELETE」を実行します。

すぐに処理が進み、1分ほどでVPC Peering接続が解除されました。

NFSデータストアもVPC Peering接続もない初期状態になりました。

このSDDCはこれ以上利用しないので、SDDCも削除しておきます。

VPC Peeringの接続解除の後始末 (AWSマネジメントコンソール側作業)

AWSマネジメントコンソールから「VPC」に遷移し、「Peering Connection」を確認します。
VPC Peering接続が解除されたので、当然ながら削除されています。

ですがルートテーブルには「Target」として残り続けており、Blackholeとなっています。

不要なルートテーブルのエントリーは削除しておきます。これで後片付けは完了です。

5. FSxN (NFSデータストア)を別SDDCから再利用し、格納されている仮想マシンを復旧させる

M7i環境でNFSデータストアとして利用したFSxN (Single-AZ, 1TiB)を、今度はI4i環境からNFSデータストアとして再利用してみます。その後、格納されている仮想マシンを再度起動させます。

VMware Cloud on AWS I4i環境の作成

今回はI4iインスタンス x1ホストの環境を作成します。

作成時点では外部ストレージが存在しないので、内蔵ストレージ(vSAN)のみが利用されています。

vCenterから見ても、利用できるのは「WorkloadDatastore」のみです。

I4i環境からFSxNをNFSデータストアマウント

上述のM7i環境と同様に、対象のFSxN (Single-AZ, 1TiB)をNFSデータストアマウントします。
FSxN用VPCとFSxN自体はすでに作成済みなので、この作業はすぐに完了します。

「Summary」タブからも確認すると、「External Storage」として表示されています。

vCenterでも同様にNFSデータストアが確認できます。

FSxNに格納されている仮想マシンをインベントリーに再登録

NFSデータストアの「Files」を確認すると、M7i環境で作成後にインベントリーから登録解除しておいた仮想マシンのイメージデータが確認できます。

この時点では「VMs」のタブには当然どの仮想マシンも登録されていません。

「ACTIONS」から「Register VM」を選択します。

再度インベントリーに登録したい仮想マシン(今回はUbuntu Linux仮想マシン)を選択します。

任意の仮想マシン名を入力し、選択可能な任意の仮想マシンのフォルダを選択します。

選択可能な任意のコンピュートリソースを選択します。

選択内容を最終確認し、「FINISH」に進みます。

インベントリーに対象の仮想マシンが再度登録できました。

同じ手順を繰り返し、他の仮想マシンもインベントリーに再度登録します。

インベントリーに再度登録した仮想マシンの起動

対象の仮想マシンを起動させていきます。

インベントリーから再度登録したままの状態では、「Network Adapter」の設定が新しい環境に対応できていません。

「Network Adapter」を利用可能なネットワークに設定変更します。

設定変更の後、仮想マシンを起動させます。
これで完了です。無事、M7i環境で作成した仮想マシンをI4i環境でも再利用することができました。

6. おまけ1: VMware Cloud on AWS M7i環境に VMware HCXをデプロイ

作成した VMware Cloud on AWS M7i 環境でVMware HCXをデプロイしてみます。

おっと・・・。
2024年3月時点では、Vmware HCXをM7iインスタンス環境でデプロイする際には各SDDC環境ごとにVMware SupportにSRチケット起票する必要があるようです。

ちなみに他インスタンスタイプ「i3.metal」「i3en.metal」「i4i.metal」の場合はVMware Supportへの依頼は必要ありません。

というわけで、VMware SupportにSRチケットを起票します。

チケットはすぐに受領され、数営業日後に完了したとの通知あったので、再度HCXのデプロイを実行します。
今度はうまくHCXのデプロイがスタートしました。

HCXのデプロイ作業が自動で行われます。

しばし待つと、HCXがデプロイされました。

管理系VMのデータストア(managementDatastore)の中に格納されています。

最後にHCXにログインして、完了です！

VMware Cloud on AWS M7iインスタンスのFAQ

よく見ると、FAQにもM7i環境におけるVMware HCXデプロイについて記載がありました。

7. 前回記事

8. 参考資料