本記事は全三回の連載になっています。本記事は全三回の連載になっています。興味のある方は他の回のコンテンツもご覧ください。
第1回: Nutanix Xtract for VMsは使えるのか？
http://blogs.networld.co.jp/main/2017/12/nutanix-xtract--61ff.html
第2回: Nutanix Xtract for VMs Deep Dive ～データ転送の裏側～
http://blogs.networld.co.jp/main/2017/12/nutanix-xtract--342e.html
第3回: Nutanix Xtract for VMs Deep Dive ～ハイパーバイザー変更を吸収する仕組みとは～
http://blogs.networld.co.jp/main/2017/12/nutanix-xtract--ae65.html
はじめに
ここまではXtract for VMsを使ったvSphere環境からAHV環境へ移行する仕組みをデータ転送の仕組みから紹介してきました。今回はvSphere環境のESXiからAHV環境へハイパーバイザーを変更した場合に、「ゲストOSにどういった変更が起こるのか？」「変更をどうやってXtract for VMsが吸収しているのか？」といったところを掘り下げて紹介してみたいと思います。
ハイパーバイザー変更の影響とは？
昔々、「仮想サーバ」が当たり前になる前の時代は、サーバに直接OSをインストールして利用する「物理サーバ」が一般的に利用されてきました。vSphereを始めとするサーバ仮想化ソリューションを導入する際には、Physical Server(物理サーバ)からVirtual Server（仮想サーバ）に移行するためにP2Vと呼ばれる移行作業が必要でした。例えばvSphereの場合vCenter Converterと呼ばれるツールが提供されていて、物理サーバから仮想サーバに容易に行えるようなツールが提供されていました。
物理サーバから仮想サーバに移行する際に注意が必要な事項には以下のようなものがありました。
・ハードウェアが変更される
・元々導入されていたハードウェアのユーティリティが悪さをする
・元々導入されていたセキュリティソフトが悪さをする
物理サーバの場合、HPE社のProLiantの場合、DELL社のPowerEdgeの場合などサーバベンダーごとにインストールされるユーティリティが異なったり、利用していた共有ストレージがあったりすると、ストレージベンダーが提供されるユーティリティも入っていたりと、サーバごとにハマりどころがあったりしました。
Xtract for VMsは移行元環境はESXiだけを想定すればいいため、こういったハマりどころはありませんが、ハードウェアの変更やMACアドレスの変更といったものはP2Vと同様で発生します。
Xtract for VMsは移行元仮想マシンにエージェントソフトなどを導入することなく移行可能というのがウリの1つだったりしますが、移行時には自動的にこういったハイパーバイザーの変更を吸収するためにスクリプトだったりドライバのインストールだったりが行われます。
だったりで済ますと話が終わってしまいますので、皆さんが興味をお持ちの裏側でどういった処理が実行されているのか前回同様ログファイルから追ってみたいと思います。
ハイパーバイザー変更に備えるXtract for VMsの裏側～移行前処理～
Xtract for VMsではハイパーバイザーの変更に備えて、様々なタスクを実行します。例えばvSphereで利用していたディスクコントローラはAHVではVirtIOに切り替わります。例えばWindows OSではInboxではVirtIOのドライバはもっていません。そのため何も対策をしないで移行しても、AHV環境で移行元の仮想マシンを起動してもシステムディスクが検出できずに起動すらできません。
Xtract for VMsではこういったことを防ぐために移行元仮想マシンが移行元ハイパーバイザーで稼働している状態でもいくつかのタスクを実行しています。これらのタスクを実行する前にはスナップショットを取得しているため、万が一何かあったとしても容易に元の状態に復帰することが可能です。
xtract-srcagent.logファイルをざっと眺めてみると、以下のようなタスクが実行されていることがわかります。
- Checking admin permissions
- Checking windows installer version
- Adding Nutanix sha1 certificate
- Adding Nutanix sha2 certificate
- Loading user profile
- App Mobility drivers are NOT installed
- Setting SAN Policy=OnlineAll
- Retaining IP information
これらのタスクが実際にどんなことをやっているのか、なぜ必要なのか見ていくことにしましょう。ログファイルをみると実際にこれらのタスクを実行時に呼び出されているスクリプトファイルも確認することができます。これらのタスクで必要なファイルはXtract for VMsの仮想アプライアンスの中の「/opt/xtract-vm/resources/」に保存されているファイルが適宜移行対象の仮想マシンにアップロードされて実行されているようです。
Checking admin permissions
これはわかりやすいですね、そのままの通りでXtract for VMsではMigration Planを作成する際にゲストOSの認証情報を入力する必要があります。この入力したユーザアカウントがこの後のタスクで必要になるローカルAdministratorの権限を持っているかどうかの確認を実施しています。
Checking windows installer version
これはこの後のタスクとしてAHV環境で必要なドライバ群をインストールする際に要求されるWindowsインストーラのバージョンを確認しています。msiexec.exeファイルのバージョンを確認して一定以上のバージョンでない場合、エラーを返すようになっているようです。
Adding Nutanix sha1 certificate / Adding Nutanix sha2 certificate
なんで証明書なんて追加しているの？と思われるかもしれませんが、昨今のWindowsではドライバ署名の証明書が不正だとそもそもインストールできないといったことがあります。そのため事前に証明書ファイルをコピーしてインストールするといった流れを自動的に行っています。
Loading user profile
これは…。何者なんでしょうかね？きっと以降のタスクでユーザプロファイルに含まれる環境変数とかが必要だから読み込んでいるんじゃないかと推測しています。
App Mobility drivers are NOT installed
AHVで必要になるドライバ群（App Mobility drivers）をインストールします。これによってAHV上での初回起動時にシステムディスクが見つからないといったことがなく起動が可能になります。事前にインストールしておくだけなので、移行元仮想マシンの再起動が必要といったこともありません。
Setting SAN Policy=OnlineAll
SANなんて構成してないけど…って思われる方もいらっしゃるかもしれませんが、Windowsのディスク管理のポリシーの名前がSAN Policyです。最近のWindowsに対してホットアドでディスクを追加（拡張ではない）すると、追加したLUNがオフライン状態で認識していることにお気づきでしょうか？
これはWindows OSのSAN Policyの設定が既定ではオフライン共有になっており、新規のLUNを検出したときの動作はオフライン状態となります。それではDドライブ等がオフライン状態で起動されてしまい、アプリケーションが正常に動作しなくなることになります。そこで常にオンライン状態となるようにポリシーを変更するためにdiskpartコマンドを実行してから移行を実施しています。
Retaining IP information
これもその名前のとおり、移行元仮想マシンのIPを保持するためのタスクになります。先ほどハイパーバイザーを変更する際にハードウェアが変更になると説明しましたが、Windowsではハードウェアが変更されると「ローカルエリア接続＃2」というようなインターフェースが新規作成され既存の「ローカルエリア接続」の設定を引き継ぐことはできません。
そこでXtract for VMsでは事前に既存のネットワーク設定のバックアップを取得して、移行後の初回起動時にネットワーク設定のリストアを実施することで力業ではありますがネットワーク設定を引き継ぐことを可能にしています。但し現在のバージョンのXtract for VMsはこういった若干力業でネットワーク設定を移行していることもあり、NICの順序などを意識しなくてはいけない2個以上のNICを持った仮想マシンの移行時にはネットワーク設定を引き継ぐことができないような仕様になっています。この場合、この後紹介する移行後処理として手動でIP設定を引き継ぐ必要があります。
ハイパーバイザー変更に備えるXtract for VMsの裏側～移行後処理～
Xtract for VMsでは移行後のクリーンアップは自動では行われません。管理者が移行完了後に行う必要があります。不要になったVMware Toolsのアンインストールや、非接続状態のデバイスの削除はAHVに移行が行った後で、必ずスナップショットを取得してから実行しましょう。
まとめ
ここまで3回にわたってXtract for VMsを使ったvSphere環境からAHV環境への移行について紹介してきました。Xtract for VMsのような移行ツールは裏側の動きがブラックボックスになっているとなかなか怖くてとっつきにくいですが、こうして中身がわかってくると安心して利用いただけるのではないでしょうか？
Xtract for VMsを利用することで、お使いのvSphereの環境からシステム停止の時間を最小限にして移行を行うことができます。今まで既存システムの移行がハードルでＡＨＶの採用を見送ってきた方は、是非一度Xtract for VMsを使った移行を検討していただければと思います。
