本記事では、VMware Flingsで提供される無償のCross vCenter vMotionツールについて紹介します。
前回までの記事は以下です。
既存環境からvSAN 環境へのMigration：その① 【イントロダクション】
既存環境からvSAN 環境へのMigration：その② 【PowerCLIのInstall】
既存環境からvSAN 環境へのMigration：その③ 【既存環境からのvMotion】
【VxRail】 続・既存環境からvSAN 環境へのMigration【実環境向けのコマンド考察】
本シリーズの久々の投稿となります。
本シリーズは、Non-Shared SSO環境（≒ ELMなし）のvCenter間でのvMotionについて、PowerCLIを利用した方法を解説してきました。
今回はPowerCLIから離れて、より簡単に同じことが実施できるツールについて紹介させていただきます。
VMware Flingsとは？
今回紹介するツールはVMware Flingsで公開されてます。
VMware Flingsとは何なのか？という疑問に思う方もいらっしゃると思います。
VMware Flingsのサイトにアクセスするとトップに以下の説明（？）がありました。
Flings are apps and tools built by our engineers and community that are intended to be explored.
つまり、vmwareの有志のエンジニアが作成している各種便利ツールをやアプリを公開している場です。（だと理解してます）
ここで公開されているツールは、基本的にvmware製品サポートには含まれませんが、便利だと思います。（需要があれば）
Cross vCenter Workload Migration Utility
今回ご紹介するツールは、以下のURLからダウンロードできます。
Cross vCenter Workload Migration Utility | VMware Flings
使い方は非常に簡単で、JRE（Java Runtime Environmen）がInstallされているWindows PCで実行するだけです。
ダウンロードページのInstructionと、Look & Feelで使えるとは思いますが、改めて本ブログでも紹介させていただきます。
メリットとデメリット
メリット
非常に簡単
コマンドを打たなくていい
環境要件が緩い（PowerCLIも不要）
PowerCLIでネックとなった、vNICの接続ポートグループも個別に指定可能
デメリット
ツール自体はサポート対象ではない（PowerCLIも通常のサポートには含まれないので差はないかも？）
失敗した場合のトラブルシューティングには、通常のCross vCenter vmotionと同等の知識が必要となる
環境要件
Requirementは以下のようになっています。
- vCenter Server 6.0 Update 3 or above (ESXi hosts must also be 6.0u3+
- Java Runtime Environment 1.8-10
- Web Browser
- Please review https://kb.vmware.com/kb/2106952 for Cross vCenter vMotion requirements
注意点は特にないです。vSphere 6.x以降であれば6.0~6.5~6.7で相互にvMotionすることも可能です。（執筆時点では7.x以降との互換性については不明）
Javaは1.8.-10となってますが、筆者の環境はJava Build 1.8.0_231で動いてますので厳しい制限ではないと思います。
Javaが入っていればWindowsに限らないはずですが、筆者は試してません。
ブラウザはChromeでOKです。
Cross vCenter vMotionの制限はKBを参照いただく通りですが、EnterprisePlusライセンスが必要、という点は重要です。それ以外は工夫で何とかなると思います。
使い方
Note: Windows環境での利用を想定しておりますが、Linux環境でも同様だと思われます。
まずはファイルをダウンロードしましょう。
使い方は非常に簡単で、PowerShellかコマンドプロンプトを開いて、ダウンロードしたjarファイルを以下のような形で実行してあげるだけです。
PS C:\Users\Administrator\Downloads> java -jar .\xvm-3.1.jar
ファイル名は実際にダウンロードしたファイル名を指定してください。Versionにより異なります。
公式のInstructionでは起動時にvCenterの情報を指定する方法が示されていますが、指定せず後で入力する形のほうがシンプルですので、こちらの方法を採用しています。
実行が完了すると以下のような出力が出ます。
PS C:\Users\Administrator\Downloads> java -jar .\xvm-3.1.jar
14:48:00 INFO *** Cross vCenter vMotion Utility ***
14:48:02 INFO Starting ApiController v3.1 on SAMPLEPCNAME with PID 8016 (C:\Users\Administrator\Downloads\xvm-3.1.jar started by kanedn in C:\Users\Administrator\Downloads)
14:48:04 DEBUG Running with Spring Boot v2.0.3.RELEASE, Spring v5.0.7.RELEASE
14:48:04 INFO No active profile set, falling back to default profiles: default
14:48:09 INFO Using app port 8443. The default port is 8443 and can be changed by using the -Dserver.port flag
14:48:09 DEBUG Initialized controller with empty state
14:48:13 INFO Started ApiController in 12.276 seconds (JVM running for 15.589)
14:48:13 INFO XVMotion app initialized successfully!
ここまで出力されていれば、実行は完了です。
JavaのプログラムがWindows PC上で実行されてますので、ブラウザでアクセスしましょう。
デフォルトでは8443ポートが利用されます。変更することも可能ですが、多くの場合は変更不要と思います。
ページが開いたらまずMigrateボタンを押します。
次にRegisterボタンを押します。押した先でソースとターゲットになるvCneterを登録します。
この段階ではまだ何も登録されていないはずですが、登録されているvCenterがある場合は以下のように表示されます。
新規で登録する場合はフォームに従って必要な情報をいれてSubmitを押します。
ソースとターゲットの両方を登録しましょう。
２つ登録されていると以下のようになります。
登録が終わったらMigrateボタンをして、vMotionの設定に移ります。
※vMotion Utilityという名前ですが、Cold Migrationも可能です。
必要事項を入力してSubmitを押すだけです。
実行開始るとTask Informationのページに移ります。
おっと、今回はすぐにErrotとなってしまいました。
errorのところをクリックするとInfoのところに原因などを教えてくれます。
が、個々の情報だけではわからないことが多いです。
問題が発生した場合は、vCenter側のログを見る必要があります。
vMotionが開始されるとソースのvCenter側でもタスクができます。Taskの実行状況はvSphere ClientのGUIから確認できます。
失敗した場合は、Taskのエラーメッセージから何か判断できることもあります。
Taskのメッセージからも判断できない場合は、vCenterやESXiのログを見る必要があるでしょう。
原因を排除してvMotionがうまいく言った場合、Task InformationのStatusがRunningになり、Progressバーが進行してやがて100％になります。
100%になってもすぐに終了ではなく、StatusがRunningからSuccessになるのを待ちましょう。Successになるまで終了ではありません。
なお、RunningになればGUIを閉じてもTaskは中断されず最後まで実行されます。
トラブルシューティング
今回はラボ環境でしたが数多くの失敗に遭遇しました。
失敗した場合は以下の流れで見ていくのが良いと思います。
１．Cross vCenter Workload Migration Utility のWebUIのErrorメッセージ
２．Utility 起動時に利用した、PowerShell実行画面のメッセージ
３．各vCenter GUIの最近のタスクと詳細情報
４．vCenterのログ（vpxd.log）
５．ESXiのログ（vpxa.log およびhostd.log）
代表的な失敗例を挙げてみましたので、トラブルの際にはご参考にしていただければ幸いです。
仮想ハードウェアVersionに互換性がある
DVSのversionがおなじ（踏み台VDSが必要）
TargetはClusterではなく単体ホストを指定。（Not RespondingがあるためCluster指定だとうまくいかない場合がある。）
vCSAがお互いに名前解決可能
vMotionネットワーク間で疎通がある。
１は移行先のClusterで仮想ハードウェアのバージョン相互運用性がある必要があります。Versionの新しいほうから古いほうに移行する場合に注意が必要です。
２はDVS Versionの制限です。移行先と元でVDS Versionが同じである必要があります。VDSは複数持てるので、同じVersionのVDSを踏み台VDSとして作成すれば問題ありません。
ただし、踏み台VDSには最低でも1つ以上のUplinkが必要です。Uplinkがない場合はVDSの候補として出てきません。
３は、移行先のターゲットリソースとして、Clusterではなく、ホスト単体を指定したほうが良い、という経験上のBest Practiceです。Cluster配下のHostに障害（Not Respondingなど）がある場合、移行が失敗することがあります。そういう場合は単体ホストを明示的に指定して移行を開始すれば回避できます。ただし、この方法では自動で負荷分散がされないので注意が必要です。移行した先にDRSによる負荷分散が実行される場合もあると思いますが、すべてのvMotionを単体ホストで実行した場合、vMotionの同時実行数の制限に抵触する可能性がありますので、やはり移行の段階から分散したほうが無難です。参考：Limits on Simultaneous Migrations
４は、名前解決の問題です。vCenterが対向サイトのリソース（vCenterやHostなど）を見つけるときに名前解決が必要となります。DNSの設定に留意ましょう。
５は、vMotionネットワーク間での疎通についてです。当然ながらソースホストとターゲットホストでvmotionネットワークに疎通がなければvmotionできません。
vmotionネットワークの疎通が難しい場合、Cold Migration （仮想マシンがPowerOff状態）にすれば、Management ネットワークが利用されますのでワークアラウンド可能です。
1以外は基本的にどうにかなりますが、１の仮想ハードウェアは一度上げたものは下げれません。Versionの古いClusterに移行する可能性がある場合は、仮想マシンを作る段階で6.0~6.7で互換性のあるVersionを選んで置き、迂闊にUpdateしないことが重要です。
いかがでしたでしょうか？正直なところ、苦労してPowerCLIでやるよりもこっちのほうがいいと思います。
サポート対象でない、という点ではPowerCLIとほぼ同等ですし、こちらのツールであればPowerCLIのように作りこむ必要性がありません。
ぜひお試しいただければと思います。