cjnotes

VMware Cloud on AWS の IPsec-VPN 設定を行うには？(Azure編)

CJです。

VMware Cloud on AWS (以下、VMC on AWS)のとても魅力的な活用方法の一つとして、オンプレまたはクラウド環境と接続を行い、DRサービスとして使う方法があります。今日は、そのキーとなる接続方法について共有したいと思います。

では、早速構成イメージから見ていきましょう。

接続の想定イメージ

VMware Cloud on AWS の SDDC と Azure 間の接続構成イメージ図

検証のゴール

VMC on AWS 上に存在する vCenterと、Azure上で稼働中の仮想マシン(CJ-01)間で、疎通(ping 確認)ができるようになる。

事前準備

以下のように、パラメーター(シート)を事前に用意いただくのが、混乱を防ぐ為、おすすめです。また、当然事前に確認できない値などは、作成と共に埋めて行ければ大丈夫です。

	VMC on AWS (SDDC)	Azure
Public IPaddress	xxx.xxx.xxx.xxx	zzz.zzz.zzz.zzz
Private Network (CIDR)	192.168.10.0/23 (Infrastructure Subnet)	10.5.0.0/16
VM IPaddress (Private IPaddress)	192.168.11.196 #vCenter	10.5.7.4 #CJ-01
Encryption	AES 256	AES 256
Diffie Hellman	DH2	DH2
IKE version	IKEV1	IKEV1
SHA version	SHA1	SHA1
Pre-shared key	CJkey!	CJkey!
Firewall Rules	ICMP 接続許可	–

VMC on AWS のIPアドレスは、SDDCコンソールの Network (Network & Security)タブから確認できます。また、vCenter のIPアドレスは、Support タブから確認できます。

設定の流れ

Azure : Virtual Network を作成
Azure : Virtual Network Gateway を作成
Azure : Local Network Gateway を作成
Azure : Connection を作成
Azure : 仮想マシンを作成 (本記事では割愛させていただきます。)
VMC on AWS : VPN 設定を行う

1. Azure : Virtual Network を作成

Azure : Home > Virtual Networks > Create virtual network

2. Azure : Virtual Network Gateway を作成

*Azure : Home > New > Virtual network gateway > Create virtual network gateway*

3. Azure : Local Network Gateway を作成

*Azure : Home > New > Local network gateway > Create local network gateway*

4. Azure : Connection を作成

*Azure : Home > New > Connection > Create Connection*

*Azure : Home > CJ-vNet-GW-CJ-LocalNet-GW*

上記のように Connection 作成が終わったら、”Download configuration” をクリックし、Azure側の IPsec パラメーター情報を確認・事前準備シートに追記してください。

Cisco、Juniperなどが選択が可能ですが、ここでは Generic Samples を選択します。

Network parameters & IPsec/IKE parameters 情報が確認できます。
想定指定たパラメーターで合ってるかどうか、および IPsecパラメーター情報を事前準備シートに追記してください。

5. Azure : 仮想マシンを作成

仮想マシンの作成方法については、本記事では割愛させていただきます。
現在、作成済みの仮想マシン (CJ-01)は、上記のように稼働中であることがわかります。
*Azure : Home > New > Virtual Machines > CJ-01*

6. VMC on AWS : VPN 設定を行う

VMware Cloud on AWS Console > SDDCs > Network (Network & Security) > Management Gateway > IPsec VPNs > ADD VPN

IPsec 接続完了

Azureの Connection、VMC on AWSの VPN 共に Status が、Connectedとなっていれば、この図のように IPsec VPN接続が完了している状態となります。

Azure (CJ-01) から、VMC on AWS (vCenter) へ Pingが通ることが確認できます。

いかがでしょうか。

数分の操作を行うだけで、簡単に VMC on AWS とクラウド(Azure)間が、疎通できるようになりました。はじめは多少混乱する可能性もありますが、上記の事前準備シートを予め用意いただくだけで、スムーズに設定が可能かと思います。

ぜひご自身の状況に合わせて、ご活用ください。

[参考情報]

Use the Configure MGW VPN Wizard to Configure a Management VPN and Gateway

Create a Site-to-Site connection in the Azure portal

VMware Cloud on AWS 資格を取得しました。

CJです。

先日、vExpertを受賞いただいた際に、この先は VMware Cloud on AWS (以下、VMC on AWS) についても共有して行きたいとお伝えました。今日はその一貫として、より適切な知識が共有できるようにまずは以下の関連資格を取得してみました。これからよりお役に立つ情報がお届けできればと思います。

なお、VMC on AWS はリリース頻度も多く(今年２月でも４回ほどリリース更新がありました。)、日々進化している状態です。現時点は SDDC Version 1.6 ですが、進化に伴い試験内容も更新されて行くと思いますので、本資格にご興味のある方は、試験前に極力最新情報をキャッチアップしていただくことをおすすめします。

VMware Cloud on AWS – Software Defined Data Center 2019

[参考情報]

VMware Cloud™ on AWS Release Notes

vExpert 2019 をいただきました。

CJです。

本日、vExpert 2019 Award Announcement があり、昨年に続き 2019もいただきました。素敵なvExpertコミュニティの一員として選んでいただき、ありがとうございます。@VMware

今年は、既存の vSANはもちろん、最近話題の “VMC on AWS” についても紹介して行きたいと思いますので、引き続きよろしくお願いいたします。

VMC on AWS の中身とは？

CJです。

2018年11月12日より、東京リージョンでの提供が開始されている VMware Cloud on AWS (以下、VMC on AWS) の中身(ホスト中心)がどうなっているかについて簡単に共有したいと思います。

VMC on AWS とは？

以下のように、VMware社が提供するクラウドサービス(VMware Cloud Services)の一つであり、オンプレの vSphere 環境をパブリッククラウド(AWS)環境まで拡張できるとても魅力的なサービスであります。

VMC on AWS イメージ図

以下の通りに、AWS基盤上に “vSphere(Computing), vSAN(Storage), NSX(Networking)”コンポーネントを使って vSphere 環境(SDDC)の構築が可能です。

また、構築された環境は、オンプレの vSphere環境ともハイブリッド接続ができるため、慣れている vSphere UIそのままを使って各自の状況に合わせた形でパブリック側への拡張が可能です。もちろん、AWSが提供する各サービスと連携することも可能です。

引用ソース：VMware Cloud on AWS: Technical Deep Dive articles: February 2019 Recap

VMC on AWS のESXi バージョンは？

VMC on AWS は VMware社が vSphere環境のアップデートなどのメンテナンスを行っており、基本、最新の ESXiバージョンを使用しているようです。

その証拠(?)がこちらです。

なんと、ESXi 6.8 でした。

VMC on AWS のホストおよび vSAN構成は？

以下のように、AWSのベアメタルサーバー (i3p.16xlarge) を利用して、vSAN構成 (ミニマム 3台より)が組まれる形となります。また、Datastoreについては、2つ (vsanDatatore と WorkloadDatastore) に分かれており、ユーザー側は WorkloadDatastoreを使う構成になります。#vsanDatastoreは Management用として使われるようです。

Networkについては、AWSのVPC中に SDDCがある形になり、NSX のコンポーネントが各接続を行うイメージになります。

引用ソース：VMware Cloud on AWS FactBook : vSAN Facts

作成可能なクラスター及びホスト数は？

クラスターは最大 10個まで作成可能。(2台までという制限も一応あるようですが、状況によっては解除できるようです。)

ホストについては、クラスタあたり 16台まで作成可能。#minimum 3台より。

簡単ながら共有したかったのは以上ですが、いかがでしょうか。

VMC on AWS の中身について少しご理解いただけたら嬉しいです。

[参考情報]

VMware Cloud on AWS: Technical Deep Dive articles: February 2019 Recap
https://cloud.vmware.com/community/2019/02/20/vmware-cloud-aws-technical-deep-dive-articles-february-2019-recap/

Test Environments
https://docs.vmware.com/en/VMware-Cloud-on-AWS/solutions/VMware-Cloud-on-AWS.41c9c48fd7fb1fb2844c0a2669172896/GUID-E44CBBE303507492A558E2728ECDE652.html

VMware Cloud on AWS FactBook : vCenter Facts
https://docs.vmware.com/en/VMware-Cloud-on-AWS/solutions/VMware-Cloud-on-AWS.21f8f625a36c8d3b2c9f11b3f8d684e5/GUID-E6C4179C071F0E0FEA410DEDCF396F85.html

VMware Cloud on AWS FactBook : vSAN Facts
https://docs.vmware.com/en/VMware-Cloud-on-AWS/solutions/VMware-Cloud-on-AWS.21f8f625a36c8d3b2c9f11b3f8d684e5/GUID-06C91BCB25B2808BBDE0A2629D486922.html

VMware 認定資格の有効期限(2年)が解除？

CJです。

VMware にはVMware Certified Professional (以下、VCP) などの認定資格があり、この資格を有効の状態に維持するためには、2年以内に再認定 (再受験必要)を受ける必要がありました。

ところが、この再認定ポリシーが昨日より変更されたようです。

■再認定ポリシーからの抜粋

As of February 5, 2019, VMware certifications do not have a mandatory recertification requirement.

すでにVCPの更新に間に合わなかった方も、以下のような一定条件を満たせば、2019年4月に有効状態に戻り、最新バージョンの資格更新へトライできるようになるようです。

■2019 Policy FAQからの抜粋

Data Center Virtualization:	VCP5-DCV or VCP6-DCV
Network Virtualization:	VCP-NV or VCP6-NV
Cloud Management & Automation:	VCP-Cloud, VCP6-CMA or VCM7-CMA
Desktop & Mobility:	VCP6-DTM or VCP7-DTM

以前から、VCP更新期限 (2年)についてはやはり学習を含めた準備期間を考えると短い印象がありましたが、今回の更新により多少時間の制限から解放された感があり、多くの認定資格者からは歓迎されるのではないでしょうか。

個人的には今回のポリシー変更により、幅広い製品への更新にもつながることが期待できるかと思います。

[参考情報]

RECERTIFICATION POLICY:VMWARE CERTIFIED PROFESSIONAL
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/certification/vmw-certification-recertification.pdf

VMware Recertification Rollback 2019 Policy FAQ
https://campaign.vmware.com/imgs/edu/VMware_Recertification_Rollback_FAQ.pdf?mid=24574&eid=CVMW2000040970082

ESXi へSSHログインする際に、パスワード認証が通らない場合は？

CJです。

ESXi環境を管理中、esxcli または ESXi の各種ログ情報を集録するなど、ESXiへSSH接続を行うことケースがあるかと思います。

ところで複数のESXi を管理すると、たまにはパスワード認証が通ったり、通らなかったりした経験ございませんか？

今日はどこの違いによるものかを簡単に紹介したいと思います。

パスワード認証が通る時

例として、TeraTermを使った説明とします。

このように、普通に TeraTerm を開き、接続先のESXi (例. esxi01.cj-lab.com) とポート番号(例. 22) を指定した後、ユーザー名とパスワードを入力すると ESXi へ接続ができます。

パスワード認証が通らない時

“認証に失敗しました。再実行してください。” というメッセージと共に、プレインパスワードを使う項目が選択から外ずれてしまいます。

この場合は、チャレンジレスポンス認証を試してください。

“チャレンジレスポンス認証を使う (キーボードインタラクティブ)” 項目を選択し、

適切なパスワードを入力してください。そうすると、以下の通りに正常に ESXi へSSH接続ができます。

なぜ？

パスワード認証が通る場合と、そうではない場合(チャレンジレスポンス認証が通る場合) の違いは以下の通りに ESXi の SSH config 設定が異なるためです。

#以下の例は、ESXi 6.7 U1 環境での情報となります。

/etc/ssh/sshd_config
# only use PAM challenge-response (keyboard-interactive)
PasswordAuthentication no #パスワード認証が通る場合
PasswordAuthentication yes #チャレンジレスポンス認証が通る場合

#チャレンジレスポンス認証などについてウェブ上たくさんの情報がありますので、こちらでは割愛させていただきます。

複数のESXiを管理している方で、普段SSHログインはできていて問題はないが、設定が異なること (ログインの仕方が異なる)で気持ち悪いと思う方は、ぜひセキュリティの観点を含めてこの辺の設定変更をご検討いただいたらいかがでしょうか。

Nested vSAN on vSAN を構築するには？

CJです。

vSAN環境も進化と伴いバージョンが増えてきている状態です。

vSAN環境が一つしかない状態で、最新の vSANバージョン or アップデート前の vSANバージョンなどで動作テストが必要な場合ございませんか。

今日はそのようなケースにおいて有効な方法である “Nested vSAN ” について紹介したいと思います。

全体イメージ図

まずは、全体のイメージをみるとこんな感じになります。

ネットワークの構成、各VMの細かい表現については割愛させていただきます。

※今回の例では、物理 vSAN環境と離れた基盤上で動いている vCenter から、各物理レイヤーと仮想レイヤーでの疎通ができる前提としてあります。

また、Nested環境自体を構築する方法については、既に別の方が記事を書いてありますので、そちらをご参照ください。

① まずは、物理レイヤーから : ESXi 上でのパラメーター変更

ハードウェア仮想化機能を仮想マシンに提供するため、物理サーバ上の ESXiホストで以下のコマンドを実行します（再起動は不要）。

まずは、以下のコマンドにて現状を確認しましょう。

esxcli system settings advanced list -o /VSAN/FakeSCSIReservations

そうすると、以下のように現状値が確認できます。

Path: /VSAN/FakeSCSIReservations
Type: integer
Int Value: 0
Default Int Value: 0
Min Value: 0
Max Value: 1
String Value:
Default String Value:
Valid Characters:
Description: If set, will fake SCSI reservations without enforcing them. Devel use only. Unsafe and may corrupt data if used incorrectly.

では、早速ハードウェア仮想化機能を仮想マシンに提供できるように、以下のコマンドを入力しましょう。

esxcli system settings advanced set -o /VSAN/FakeSCSIReservations -i 1
echo ‘vhv.allow = “TRUE”‘ >> /etc/vmware/config

設定後、再度確認を行うと、

esxcli system settings advanced list -o /VSAN/FakeSCSIReservations | grep “Int Value”
Int Value: 1
Default Int Value: 0

② 次は、仮想マシン (vESXi) の設定

以下の2箇所を設定します。

③ 次は、NFSを設定

※ vESXi にアタッチする仮想ディスクを、物理 vsanDatastore から切り出して使えばとても楽だと思いますが、本記事を作成している時点ではサポートされていないようです。

そのため、物理レイヤーの vSAN環境上に、仮想マシンとして NFSサーバーを作成します。(NFSサーバー自体の構築方法については割愛させていただきます。)NFSサーバーの作成が終わった後、NFSボリュームを各 vESXi にデータストアとしてみせて、ここから vESXi の vsan Diskを切り出します。

・vSAN-Cluster > ストレージ > 新しいデータストア > NFS > NFS3 > “データストア名”、”フォルダ”、”サーバー” 情報を入力。

・vESXi （VM) > 新規ハードディスク > vsan disk (Cache, Capacity) を作成。

今回は、Cache：10GB / Capacity: 100GB のディスクを作成しています。

NFSサーバー上のディスクがアタッチされていることがわかります。

NFSサーバー (今回は、CentOSで作成しています。) 内に、vESXi (esxiXX.cj-lab.com) の仮想ディスクが作成されていることが確認できます。

④ Nested-vSAN Cluster 作成

作成した vsan disk が表示されていることがわかります。必要に応じてフラッシュマークをつけましょう。

vSANを有効化して、vsanDatastoreが作成されていることが確認できます。

このように物理環境で制約がある場合、Nestedを活用すると vSANの動作確認には十分有効活用できるかと思いますので、ぜひお試しください。

[参考情報]

Nested ESXi 構築時のレシピまとめ (vSphere 6.5 + vSAN)

Caveat : Running Nested VSAN On A VSAN Cluster

https://www.thinkcharles.net/blog/2018/2/23/failed-to-reserve-drives-in-vsan-nested-environments

ESXi 6系で、起動時間が一番早いバージョンは？

CJです。

約半年前にリリース(2018.4.7)された vSphere 6.7 には、”Quick Boot” という新たな機能が追加されたこと、知っていますか？

今日は “Quick Boot” 機能をみて、ふっと純粋に以下の疑問が沸いたので検証してみた結果を共有したいと思います。

その疑問は、”ESXiの各バージョンごとに、起動時間の違いはあるだろうか？”

その前に、まずは Quick Boot について簡単に紹介させてください。

vSphere 6.7 新機能： Quck Boot

vSphere 6.7 improves efficiency at scale when updating ESXi hosts, significantly reducing maintenance time by eliminating one of two reboots normally required for major version upgrades (Single Reboot). In addition to that, vSphere Quick Boot is a new innovation that restarts the ESXi hypervisor without rebooting the physical host, skipping time-consuming hardware initialization.

上記、VMware vSphere Blog からの引用となりますが、

要は物理ホストの再起動をせず、ESXi を再起動させる機能となります。

ハードウェアの初期化が省略されるため、ESXiのバージョンアップなどのメンテナンス時間が短縮される効果があります。ちなみに、本機能はサポートされるハードウェアのみに活用できるようです。 ESXi 側で以下のコマンドにて、サポートされているかどうかの確認ができます。

/usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py

特にインフラ管理者には嬉しい機能かと思うので、ぜひお試しください。

検証構成

・比較対象の各ESXi は vSAN上の Nested 環境で用意してあります。

・各ESXi は同一物理ホスト上で動いてあります。

・各ESXiのスペックは、2Core、4GB ram で同一。

・各 ESXi のバージョンは、以下の通りです。

バージョン	Build	ESXi名
6.0U3	5572656	esxi09
6.5U1	5969303	esxi08
6.5U2	8294253	esxi07
6.7U1	10302608	esxi06

測定内容

・測定1 : ESXi が停止状態から起動完了までの “起動時間 (秒)”

・測定2 : ESXi が起動状態から再起動完了までの “再起動時間 (秒)”

測定方法

・測定1 : ESXi コンソール画面上で、ESXi ホスト名が表示される画面に繊維されたタイミングまでの時間をストップウェッチにて計測。

・測定2 : ESXi コンソールの再起動直前の画面から、F11により再起動を開始して、ESXi ホスト名が表示される画面に繊維されたタイミングまでの時間をストップウェッチにて計測。

測定結果

測定1 : なんと 6.0U3 のほうが、一番早かったです。

測定2 : 再起動は 6.7U1 のほうが、一番早かったです。

6.0U3 と 6.7U1 間には、微妙な誤差がありそうですが、6.5系と6.7U1間には差ほど大きいな違いはないようですね。数秒の差とはいえ、メンテナンスの際には規模によってこれも短縮したくなるのではないでしょうか。

[参考情報]

ESXi Hardware Requirements
https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.esxi.install.doc/GUID-DEB8086A-306B-4239-BF76-E354679202FC.html

Quick Boot Compatibility
https://kb.vmware.com/s/article/52477

Introducing VMware vSphere 6.7!
https://blogs.vmware.com/vsphere/2018/04/introducing-vmware-vsphere-6-7.html

ESXi に残っている vSAN情報を削除するには？

CJです。

vSANクラスター配下で動いている ESXi ホストを、クラスター外に持ち出すケース(クラスター内のホストを別環境に転用したい場合など)があると思います。

今日はその際に使える簡単な Tipを紹介したいと思います。

vSANクラスターから ESXi ホストを外す流れ

１．対象ESXi ホストをメンテナンスモードに切り替え

２．対象ESXi の DiskGroup を削除

3. Drag&Drop にて、対象 ESXi ホストを vSANクラスター外に移動

基本はこれだけでよいはずですが、問題は次の事象です。

対象 ESXi 上での操作 (SSH接続)

以下のコマンドにて、vSAN情報が残っていないかを確認。

esxcli vsan storage list

この結果で、vSAN Disk情報が表示された場合は、以下のコマンドにて Disk情報を削除。

esxcli vsan storage remove -u [DISKGROUPのUUID]

もし、vSAN Disk情報など何も表示されてはいないが、vSAN情報が残っていることで別のクラスター環境へ移動ができない場合は、”vdq -q” と “esxcli vsan cluster get” コマンドにて状況を確認。

vdq -q
[
{
“Name” : “naa.600605XXXXXXXXXX2270bcXXXXXXXXXX”,
“VSANUUID” : “”,
“State” : “Eligible for use by VSAN”,
“Reason” : “None”,
“IsSSD” : “1”,
“IsCapacityFlash”: “1”,
“IsPDL” : “0”,
},{
“Name” : “naa.600605XXXXXXXXXX2270bcXXXXXXXXXX”,
“VSANUUID” : “”,
“State” : “Ineligible for use by VSAN”,
“Reason” : “Has partitions”,
“IsSSD” : “0”,
“IsCapacityFlash”: “0”,
“IsPDL” : “0”,
},esxcli vsan cluster getCluster Information
Enabled: true
Current Local Time: 2018-11-05T09:33:53Z
Local Node UUID: 5afe36c2-e2a1-XXXX-XXXX-XXXXXXXXXX20
Local Node Type: NORMAL
Local Node State: MASTER
Local Node Health State: HEALTHY
Sub-Cluster Master UUID: 5afe36c2-e2a1-XXXX-XXXX-XXXXXXXXXX20
Sub-Cluster Backup UUID:
Sub-Cluster UUID: 52dc722d-a2c0-XXXX-XXXX-XXXXXXXXXX85
Sub-Cluster Membership Entry Revision: 5
Sub-Cluster Member Count: 1
Sub-Cluster Member UUIDs: 5afe36c2-e2a1-XXXX-XXXX-XXXXXXXXXX20
Sub-Cluster Membership UUID: 1a9c835b-dd2f-XXXX-XXXX-XXXXXXXXXX20
Unicast Mode Enabled: true
Maintenance Mode State: OFF
Config Generation: a2a65e3c-33ed-XXXX-XXXX-XXXXXXXXXXf2 8 2018-11-05T09:15:51.659

これで vSAN情報が残っていることがわかりました。

では、早速次のコマンドにて、vSAN情報を削除しましょう。

esxcli vsan cluster leave

これで削除が完了しました。

もう一度、vSANクラスター情報を確認してみると、以下の通りに削除されていることがわかります。

esxcli vsan cluster get
vSAN Clustering is not enabled on this host

上記コマンドは、vSphere 6.5U1 環境での動作確認済みのものとなります。

vSphere バージョンによっては、コマンドが変更されている可能性があります。

その際は、”-?” にて Help 情報を参照してください。

vSphere 6.5以降の環境から仮想マシンを OVAでエクスポートするには？

CJです。

いまさら感がありますが、vSphere 6.5 からは仮想マシンをエクスポートする際に “OVF”のみがサポートされるようになっているようです。

vSphere6.0 までは、vSphere Client が使えて、仮想マシンをエクスポートする際に OVF or OVA どちらかのファイル形式が選択可能でした。これが、vSphere 6.5 からは vSphere Web Client のみをサポートすることになり、統合プラグイン関係で OVFのみをサポートする形に変わったようです。

とはいえ、やはりファイル1個で使いやすかった OVA は継続的に使いたいですし、移行先のクラウドが OVA のみ対応しているのあれば、なおさらです。

このような状況を踏まえ、vSphere6.5 以降の環境で動いている仮想マシンを OVA にエクスポートしたい方向けにその方法を共有したいと思います。

vSphere 6.5環境で動いている仮想マシンを oVA にするには？

早速ですが、その方法は以下のように、一度 OVFでエクスポートし、それを ovftool を使って OVA に変換することです。

事前準備

ovftool インストールを踏み台サーバーにインストールが必要です。

ここでは、踏み台サーバーとして Windows を例とします。 Linux または Mac OS X も各自の環境に合わせて適切なパッケージを使えば、使用可能です。

１．OVF Tool Documentation ページへ移動して、最新バージョンをダウンロード

２．ダウンロードしたインストーラーを実行して、インストール完了。

３．環境変数に PATH を登録する (手順は割愛します)と便利。

OVFエクスポート

vSphere Web Client から “仮想マシン > テンプレート > OVF 。。。”　メニューからエクスポートを実施。ここでひとつTipとして、OVFエクスポートは HTML5版の vSphere Web Client を使用するのをお勧めします。フラッシュ版の場合、エクスポートのステータスや表示が正常に表示されないケースがあります。

OVAへの変換

OVFファイルの場所例： D:\CJ\powercli\ovftool\ovf\vcsa01_cj-lab.com.[ovf, mf, vmdk]

OVAファイルの変換先例： D:\CJ\powercli\ovftool\ova\vcsa01_cj-lab.com.ova

以下のコマンドを実行する。

>ovftool ./vcsa01_cj-lab.com.ovf ../ova/vcsa01_cj-lab.com.ova

すると、以下のようにコンバートが行われます。

最後に、”Completed successfully” メッセージが表示されれば、完了です。

いかがですか、とても簡単ではありませんか。

個人的にも OVAサポートは継続してほしいところですが、そこは vmwareさんに改善を期待しながら、今現時点ではこのような対策を活用いただければ嬉しいです。

[参考情報]

OVF Tool Documentation

https://www.vmware.com/support/developer/ovf/