【VxRail】 新・既存環境からvSAN 環境へのMigration【Flings】【Cross vCenter Workload Migration Utility】

 本記事では、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で公開されてます。

     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上で実行されてますので、ブラウザでアクセスしましょう。

 


https://localhost:8443

デフォルトでは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）

 

代表的な失敗例を挙げてみましたので、トラブルの際にはご参考にしていただければ幸いです。

    1. 仮想ハードウェアVersionに互換性がある

    2. DVSのversionがおなじ（踏み台VDSが必要）

    3. TargetはClusterではなく単体ホストを指定。（Not RespondingがあるためCluster指定だとうまくいかない場合がある。）

    4. vCSAがお互いに名前解決可能

    5. 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のように作りこむ必要性がありません。

ぜひお試しいただければと思います。

コメント

コメントを投稿

このブログの人気の投稿

vSwitchにSTPが不要な理由

イメージ
  ** 知っている人にとっては当たり前の内容です**     ESXiは多くの場合、冗長構成をとるために二つ以上のNICを利用し、それぞれ単一、もしくは別個の物理スイッチに接続されていると思います。 ESXiの物理NICはuplinkまたはvmnicとよばれ、ESXi内部にある仮想スイッチ（vSwitch）につながっています。 vSwitchはL2SWとしての役割をするため、物理スイッチをESXiの接続はスイッチ間接続となります。   図１：ネットワークトポロジ     vSwitchが物理スイッチと同等の動作をすると仮定した場合、この構成はループに相当します。 L2レベルでループがある場合は、ブロードキャストストームなどの問題が発生するためにSpanning Tree Protocol（STP）を設定する必要（最近では必ずしもそうとは言い切れないようですが。。。）があります。   ではvSwitchの場合でもSpanning Treeに参加する（ネットワークは専門外なので表現が間違っていたらすみません。。。）必要があるのでしょうか？ 表題からもわかるように答えはNoです。 L2ネットワークでBPDUと呼ばれるパケットをやり取りすることで Spanning Treeが構成されますが、実際に、vSwitchではこのBPDUをDropしますので、vSwitchのUplinkがBlockされることはありません。   ではなぜ、vSwitchではトポロジ的にLoopであるにもかかわらずSpanning Treeが不要なのでしょうか？Loopによる問題は発生しないのでしょうか？   実はvSwitchはFloodingが必要な通信に対して特殊な動作をします。 その特殊動作のため、トポロジ的にLoopであっても問題は発生せず、Spanning Treeに参加する必要がないのです。   たとえば、ARPなどの外部からのブロードキャストフレームをuplink経由でvSwitchが受け取った場合、vSwitchに接続されるVMに対してはフレームを転送しますが、ほかのUplinkに対してはフレームを転送しません。   下図ではUplink1からBroadcast Packetを受信した際の動作を示しています。 Broadcast Packetは仮想スイッチに接続されるVMに対して転送
続きを読む

ESXi に DNS サーバを何個まで登録できるか

イメージ
ESXi の DNS サーバの最大登録可能数を調べる vSphere 構築経験のある多くの方は2つまでとお答えになるかもしれない。 なぜならば、DCUI や vSphere Client から設定した場合、Primary DNS と Alternative DNS の2つまでしか設定できないからだ。 GUI から設定する場合、苦し紛れにカンマ区切りなどで3つ以上登録しようと試みても無駄である。GUI でエラーになってはじかれるだけだ。 ならば、CLI はどうか。 /etc/resolv.conf に手動で追記していくだけであればストレージの許す限り記載することはできるだろうが、 この方法は当然ながら標準的な手順ではない。 esxcli を利用して DNS を登録することも可能である。具体的には以下のコマンドを利用する esxcli network ip dns server add -s <ip_address> 上記のコマンドを利用してどこまで登録可能かを試してみた。 具体的には以下のコマンドを用いて255個のDNSサーバを追加してみた for i in `seq 1 255`; do esxcli network ip dns server add -s 192.0.2.$i ;done なお、本ブログで記載される IP Address は例示用に予約されたものであり、RFC5737 から拝借している。 結果として、少々時間はかかるが登録自体は問題なく成功した。 実環境においてこれほど多くの DNS の登録をすることはあり得ないので、事実上制限なしと考えられる。 なお、参考のために他ベンダーも含める形で DNS 登録数の最大数を調べたところ、2 か 3 にしているところが多いようだ。 DNS を大量に登録した際の動作を調べる DNS クエリのタイムアウト時間：5 秒則 ESXi の DNS Client は最近の systemd-resolved などではなく、レガシーなソフトウェアであるため、 resolv.conf の上から順番に問い合わせていき、問合せ先の DNS に到達できなかった場合に次の DNS サーバに問い合わせる動作になる。 次の DNS サーバに問い合わせる条件はあくまでも到達できなかった場合であり、到達できた
続きを読む

障害でVDSから切断されたVCSAの復旧方法

この投稿は vExpert Advent Calendarの10日目です。 https://adventar.org/calendars/6689 本記事では以下の状況と、簡易な復旧方法について説明します。 環境 vCSAは自身が管理するvSphere Cluster上に存在する。 vCSAは自身が管理する vDSに接続される vCSAが接続されるdvportgroupはEphemeralではない 該当のvCSA以外にvSphere Clusterを管理できる vCSA は存在しない  障害状況 vCSAは何らかの理由により、もともと存在していたESXiから、別のESXiに再登録されている。 vCSAはvDSから切断されてしまっている。 解説 上記の状況は、ESXiの障害などによって副次的に発生しうる状況です。もともと、vCSA は vDS に接続されていましたが、ESXi の障害などにより、いったん Guest OS から Shutdown され、Host Client を利用して別の ESXi に再登録したうえで起動しています。 この場合、もともとvCSAが接続されていたdvportは別の ESXi 上のポートであるため、起動時にvCSAはvNICを接続することができず、切断状態となります。 vCSAが切断状態になり、かつESXiのHost Clientからは仮想マシンをvDSに接続することができないため（Ephemeral Port を除く）、vCSAの復旧が困難となります。  この状況において有効な解決策としては事前に用意しておいたEphemeral Port を利用するか、もしくは一時的にVSSを作成して復旧する方法が一般的な方法です。 事前にEphemeral Port の準備がない場合には、VSSを作成することになりますが、Uplinkに空きがない場合は、Uplinkを付け替える必要があり、手順は複雑になります。 今回はVSSを利用しない簡易な復旧方法についてご紹介します。 簡易な復旧方法 完結に手順を示すと以下です。 vNICが切断されているVCSAをShutdown  vCSAが存在する ESXi を Maintenance Mode～Reboot  vCSA を再度起動～vNICが接続状態であることを確認  上記に示した通り、ESXiをリブート
続きを読む