スキップしてメイン コンテンツに移動

【VxRail】既存環境からvSAN 環境へのMigration：その③ 【既存環境からのvMotion】

 **** 留意事項 *****

こちらのブログの内容はDECN（Dell EMC Community Network）に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

 

本記事ではPowerCLIのMove-VMコマンドレットを利用したVM移行について紹介します。

 

前回と前々回の記事は以下です。

 

既存環境からvSAN 環境へのMigration：その① 【イントロダクション】

既存環境からvSAN 環境へのMigration：その②  【PowerCLIのInstall】

続・既存環境からvSAN 環境へのMigration【実環境向けのコマンド考察】

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

 

 

前回まででPowerCLIのInstallは完了していますのであとは実際にコマンドレットを発行してvSAN ClusterであるVxRailに既存環境からVMを移行します。

 

イントロダクションの記事でも説明しましたが、VxRailを想定しているため、今回は以下の環境での移行を想定しています。

  • 既存および新規（VxRail）環境のそれぞれで独立したvCenterを持つ
  • それぞれのvCenterはSSO ドメインを共有していない（拡張リンクモードでない）
  • 共有ストレージがない

 




    ※こちらの図は以下の資料より抜粋しています。

・Migrating to vSAN

https://core.vmware.com/resource/migrating-vsan

 

 

 

 

移行の際はMove-VMコマンドレットを使用します。具体的な使用方法は上記の資料、および以下のBlogにも載っています。

 

・VMware PowerCLI Blog

https://blogs.vmware.com/PowerCLI/2017/01/spotlight-move-vm-cmdlet.html

 

 

 

もっと簡単に参照する方法として、PowerCLIからMove-VMのコマンドヘルプを見る方法があります。

 

    Get-Help Move-VM -full

 

    ※クリックして画像を拡大してください


 

 

上図のヘルプからもわかるようにPowerCLIで実施するのは以下です。

  • 既存環境のVCにログイン
  • 新規環境（VxRail）のVCにログイン
  • 移行対象VMのObjectを取得（$vm）
  • 移行先のホストObjectを取得（$destination）
  • 移行対象VMのネットワークアダプタ(vNIC)のObjectを取得（$networkAdapter）
  • 移行先のdvportgroup のObjectを取得（$destinationPortGroup）
  • 移行先のvSAN データストア Objectを取得（$destinationDatastore）
  • ↑で入手したObjectを指定して、Move-VMコマンドレットを実行

 

 

では実際の例を紹介します。

 

 

 

まずはGet-Credential コマンドレットを使って、VCにログインする認証情報を$creとして保存します。

コマンドを実行するとポップアップが出るので認証情報を入力してください。

※今回の例では既存VCと新規VC（VxRail）で同じ認証情報を利用しています。異なる場合は別々に保存してください

 

    $cre = Get-Credential

 

 

 

 

 

 

認証情報を保存できたら、Connect-VIServer（もしくはGet-VIServer）コマンドレットを利用して両VCにログインします。

-Credential オプションで先ほど保存して認証情報を引数として渡します。

 

    Connect-VIServer -Server  <vCenter FQDN> -Credential $cre

   

 

 

 

両VCにログインできたら既存環境のVMから移行対象のVMを探します。

下記の例ではVM 名に joeを含むVMの一覧の中から、一つのVMを指定して$vmに格納しています。

 

    Get-VM -Server non-vxrailVC -Name *joe*

    $vm = Get-VM -Server non-vxrailVC -Name *joe*

 

 

 

 

次に移行先となる新規環境（VxRail）クラスタの中から移行先ESXiを指定します。

以下の例ではhostnameに 01 を含むESXiを指定しています。

 

    $destination = Get-VMHost -Server vxrailVC -Name *01*

 

 

 

 

 

 

次に移行対象VMのvNIC情報を取得します。

 

          $networkAdapter = Get-NetworkAdapter -VM $vm

 

 

 

 

次に移行先のVxRail上でvNICが接続されるdvportgroupを指定します。

以下の例ではVxRail上のVDSに存在するPortGroupを列挙して、その中からvCenter～で始まるPortGroupを選んで変数に格納して言います。

 

    Get-VDPortgroup -VDSwitch (Get-VDSwitch -Server vxrailVC)

    $destinationPortGroup = Get-VDPortgroup -VDSwitch (Get-VDSwitch -Server vxrailVC) -Name vCenter*

 

 

 

次に移行先となるvSANデータストアの情報を変数に格納します。

VxRail環境の場合はデフォルトからデータストア名称を変更していない限り同じコマンドで取得可能と思います。

 

    Get-Datastore -Server vxrailVC

    $destinationDatastore = Get-Datastore -Server vxrailVC -Name MARVIN*

 

 

 

 

 

最後にこれまでに取得した情報を利用して移行を開始します。

 

$vm | Move-VM -Destination $destination -NetworkAdapter $networkAdapter -PortGroup $destinationPortGroup -Datastore $destinationDatastore -RunAsync

 

※表示幅の関係で2行に見えるかも知れませんが1行コマンドですのでご注意ください。

資料やヘルプには紹介されていませんが、-RunAsyncオプションを加えることでバックグラウンド実行となりPowerCLI起因でのタイムアウトによってコマンドが失敗することがなくなります。

トラブルシューティングや実行順序を制御したいなどの場合に-RunAsyncオプションを外す場合は、前回（その②）の最後で紹介している方法にてタイムアウト値を無期限に設定してください

 

 

 

 

※実行中のvMotionタスクは移行元（既存環境）のvSphere Webclient、もしくはGet-Taskコマンドレットで確認できます。

 

 

 

 

 

ここまでの例は単一VMの移行でしたがPowerCLIの機能を使えば複数VMをまとめて移行させることができます。

以下の例ではVM名にjoeを含むVMすべてをまとめて移行させる方法の例です。

最初のコマンドで該当するVMの一覧を取得して、二つ目のコマンドで一覧を変数に格納しています。

 

    Get-VM -Server non-vxrailVC -Name *joe*

    $vms = Get-VM -Server non-vxrailVC -Name *joe*

 

 

 

あとは以下のコマンド例でまとめて実施することが可能です。

 

※単一VM移行の例と異なりVMのvNIC情報の取得がLoopの中に含まれているのでご注意ください

 

#移行先ESXiの指定

$destination = Get-VMHost -Server vxrailVC -Name *02*

 

#移行先dvportgroupの指定

Get-VDPortgroup -VDSwitch (Get-VDSwitch -Server vxrailVC)

$destinationPortGroup = Get-VDPortgroup -VDSwitch (Get-VDSwitch -Server vxrailVC) -Name vCenter*

 

#移行先データストアの指定

Get-Datastore -Server vxrailVC

$destinationDatastore = Get-Datastore -Server vxrailVC -Name MARVIN*

 

# ループ開始

foreach ( $vm in $vms) {

$networkAdapter = Get-NetworkAdapter -VM $vm

$vm | Move-VM -Destination $destination -NetworkAdapter $networkAdapter -PortGroup $destinationPortGroup -Datastore $destinationDatastore -RunAsync

}

# ループ終了

 

foreach文は｛から｝までで一つのセットですが改行を含めていただいて構いません。

以下がforeach文のコマンド実行例のGif動画です。

 

※下記のGIF動画はobama03さんにご提供いただきました。ありがとうございます。

※動画が再生されない場合はクリックしてみてください。

 




 

 

 

 

実行後は以下のようにすべてのタスクがバックグラウンドで並列実行されています。

 


 

 

 

 

同時にvMotionできる数には制限があるため、制限を超えた分に関してはQueueに入れられ実行を待ちます。

並列vMotionの制限についての詳細は、以下の資料をご参照ください

 

・Migrating to vSAN

https://core.vmware.com/resource/migrating-vsan

 

 

 

 

今回まで3回にわたって紹介した移行方法は、VxRailだけでなくほかのvSAN環境や非vSAN環境でも使用可能な方法です。

実際の環境で何百台とあるVMを正確に障害なく移行するためにいはPowerCLIにおけるスクリプトの工夫や確認作業が必要となるとは思いますが、移行の基本となる作業を理解いただけたかと思います。

 

これまでは実施が難しかった独立した新規vSAN環境（VxRail）へのVM移行手法が、簡単かつサポートされた形で提供されているのは非常に便利で安心できることなので、ぜひとも活用いただければと思います。

 

 

================  2018/08/24追記 ===================

 

続編を書きました。

続・既存環境からvSAN 環境へのMigration【実環境向けのコマンド考察】


コメント

コメントを投稿

このブログの人気の投稿

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をリブート
続きを読む