NutanixからNutanixへの移行考慮点（その3・5年を超える古いクラスターからの移行）

前回は、別のハードウェアメーカーへのリプレースを行う際の移行方法をご紹介しました。今回は、また別のケースをご紹介します。

移行課題その3/ 古いハードウェアからのリプレース

日本文化においては、7年保守での利用が見受けられます。一方で海外では3年保守、長くても5年の保守が一般的で、技術進化の観点からも、ソフトウェアも5年サイクルでの互換性を重視して設計されています。Nutanixにおいても同様で、5年を過ぎたソフトウェアからの移行に関しては、ダイレクトに移行できることが考慮されていないケースがあります。

たとえば、Nutanix NXモデルにおいては、1クラスターにおいて4世代までの混在がサポートされるというルールになっています。

▼Nutanix NXモデルの場合の世代混在ルール

この図で行くと、NX G5で構成されたクラスターにG9のモデルを混在させることは、原則できません。原則というのは、例外的にAOSが、G5とG9のモデルで同じバージョンがサポートされている場合は、例外的に同一クラスターに混在できる許可を盛られる場合もあります。（詳細は、Nutanixの営業に相談してください）

このような場合の移行についてもご紹介します。

方法1.Async DRの利用

この選択は、既存クラスターと新規クラスター（リプレース先）がメーカーサポート期間であるバージョンであれば、利用が可能です。

方法2.Nutanix Moveの利用

Nutanix Moveが一番柔軟性の高い移行方法かもしれません。こちらであれば、Async DRのレプリケーションが可能なAOSのコンパチビリティを気にすることなく移行することができます。

今回のケースでは、G5のモデルで対応するAOSでは、Cross Cluster Live Migrationに対応していないので、以上の2つが選択肢となります。今後のモデルで上記4世代ルールであったとしても、同一のAHVバージョンで双方のクラスターが稼働している条件があるため、1つのクラスターに混在ができない古いノードで構成されているクラスターとの間では、クラスター間でのライブマイグレーションは厳しい可能性が高いです。

（参考）Product Mixing Restrictions

NutanixからNutanixへの移行考慮点（その2・既存クラスターと異なるハードメーカーへのリプレース）

前回は、ESXiが導入されたNutanixクラスターからAHVのNutanixクラスターへの移行方法をご紹介しました。今回は、別のケースでの移行方法をご紹介します。

移行課題その2 / ハードウェアメーカーの変更

方法1.Async DRの利用

Nutanixは、1つのクラスター内には、1社のハードウェアメーカーで固定するルールがあります。例えばExpand Clusterで、既存Nutanix NXで構成されたクラスターにDELL XC Coreのモデルを追加しようとしても、エラーが発生しノード追加ができない仕様になっています。

そのため、ハードウェアメーカーを変更する場合同じハイパーバイザーであったとしても

この場合、Async DRを使った移行が最もメリットが高い移行方法になると思います。

AHV to AHVなので仮想マシンの変換も特に行うことなく移行を行うことができます。
スケジュール設定で定期的にスナップショットを転送しておくことと、Migrate機能を利用することで、データ差分を生まず簡単に移行ができます。また、移行切替えにおける時間も短い時間で行うことができます。

▼Async DRを使った移行

方法2.Nutanix Moveを使った移行

Nutanix Moveは、最新版のVer 6.0で確認する限り、AHV to AHVでの移行もサポートされています。（サポートされたのはMove 4.x時代だったと思いますが..）元々は、異種ハイパーバイザーからAHVへの移行ツールとして作られた製品ですが、移行環境が様々出てきたことからいろんなシーンでの移行に対応出来るように進化しています。

Moveを利用すれば、定期的なスナップショット差分を利用した移行で、移行元の仮想マシンを稼働させたまま移行データを新クラスターに配置し、最終のCutoverで切替えを行うため、短い停止時間で切替えを行うことができます。

▼Nutanix Moveを使った移行

方法3.Cross Cluster Live Migration

仮想マシンを停止せずに移行する方法としては、唯一の方法としてCross Cluster Live Migration機能があります。この機能を利用すれば、クラスター間で、仮想マシンを停止せずライブマイグレーションを利用して仮想マシンを移行することができます。

但し以下の条件があります。

• AOS 6.7以降が必要（vTPM要件がある場合は、AOS 6.8以降）
• Prism Central 2023.3以降（vTPM要件がある場合は、Prism Central 2024.1以降）が必要です。
• 2つのクラスターで物理CPUが異なる場合（リプレースは大半そうだと思いますが）、AOS 6.8以降が必要です。
• 2つのクラスターのAHVバージョンが同じである必要があります。
• 移行元と移行先で同じ名前のストレージコンテナが存在する必要があります。
• Volume Groupが接続された仮想マシンは、移行できません。
• メモリーオーバーコミットが有効化された仮想マシンは、移行できません。
• vNUMAが構成された仮想マシンは、移行できません。
• 双方のクラスターにNCI-Pro以上ライセンスが必要です

▼Cross-Cluster Live Migrationを利用した無停止移行

今回は、ハードウェアメーカーを変更したNutanixクラスターの移行についてご紹介しました。ハードウェアメーカーを変更すると、クラスター内でノードの追加・取り外しによるリプレースができませんので、違う方法を検討する必要があります。

 

Nutanix MoveでHyper-V環境におけるNIC2枚挿し構成について

今年5月の記事で、Nutanix Moveにおいて、NIC2枚構成による運用についてご紹介いたしました。

「Move利用時に既存環境とNutanixクラスターが同じネットワークにいない場合の対処法（MoveでマルチNIC構成を行う）」

こちらの手順は、KB:7399でも解説されています。

こちらの手法ですが、KBにも記載があるように、Hyper-V環境においては、この構成はサポートされていないことが記載されています。

とはいえ、Hyper-VであってもNIC2枚構成で仮想マシンを移行したいことはあると思います。

今回は、サポートされていない理由と対処法についてご紹介いたします。

＜サポートされない理由＞

まず、Hyper-V環境でサポートされない理由ですが、これは単純で、Moveの仮想アプラインスから送信するパケットの一部がNIC2枚構成にした2枚目(eth1)では無く、1枚目のNICのIPアドレス(eth0)で送信することになります。eth0のIPアドレスが送信元になったパケットが、eth1を経由してHyper-Vに届くため、受け取ったパケットの返答をHyper-Vからすると、自分が接続しているネットワークセグメント外のIPアドレスからの送信元のため、デフォルトゲートウェイに返してしまうことが要因です。

これは、Moveの現段階におけるHyper-V利用時の仕様のようです。（この仕様が改善されれば、Hyper-V環境でも2NIC構成で動作するはずです）

仕様とはいえ、それまでの話ですが、このような構成でNutanix Moveを利用したいことがあるかと思います。

＜対処法＞

※この方法はNutanixでサポートされていない対処法となります。
こちらでは、この構成を取ることによるトラブル等一切責任を負いませんので、自己責任でお願いいたします。

Hyper-Vホストにパケットが届く際に、Move VAのeth0のIPが送信元で来ると言うことは、そのパケットを、Move VAのeth1にそのパケットを返せれば疎通としては成立します。

なお、Hyper-V環境の場合、仮想マシンとMove VAが疎通できる必要がありますが、この構成の場合、もう一つの仮想スイッチを作成し仮想マシンにNICを割り当てるのも手間ですので、Hyper-Vの仮想マシンには、事前にVirto I/O Driverのインストールや。MoveのIPアドレス変更スクリプトを事前に展開しておきます。

その上で、Hyper-Vホストで
「route add <Move-VAのeth0のIPアドレス> mask 255.255.255.255 <Move-VAのeth1のIPアドレス 」
コマンドを実行します。
Hyper-Vホストの再起動後もこのルートを保持する場合は、-pパラメータを付与します。

仮に、Hyper-Vホストが172.16.21.101、Move-VAのeth1が、172.16.21.51、eth0が、192.168.1.31であった場合は以下のコマンドをHyper-Vホストで実行します。
コマンドプロンプトは管理者権限で開く必要があります。

> route add 192.168.1.31 mask 255.255.255.255 172.16.21.51

これで、Move-VAのeth0のIPアドレスをHyper-Vホストが受けても、それをMove-VAのeth1のIPアドレス宛にパケットを戻すため、通信として疎通できるようになり、NIC2枚挿しの構成であってもNutanix Moveで移行が可能となります。

「Move利用時に既存環境とNutanixクラスターが同じネットワークにいない場合の対処法（MoveでマルチNIC構成を行う）」の作業後に今回紹介したスタティックルートを追加することで、Hyper-V環境であってもNIC2枚構成で仮想マシンの移行が出来るようになりますので、困った際にはこの技も（必要に応じて）使ってみてください。

Move利用時に既存環境とNutanixクラスターが同じネットワークにいない場合の対処法（MoveでマルチNIC構成を行う）

Nutanix Moveは、既存の仮想化環境からNutanixクラスターへ仮想マシンを移行することが可能です。

このNutanix Moveはネットワークを利用して、既存の仮想環境から仮想マシンイメージを取得しNutanix側に転送する仕組みになっています。

では、既存仮想環境と新しく設置するNutanixがネットワーク的につながっていない場合、どのように移行を行えば良いかという疑問が出てきます。Nutanix Moveは、セカンドNIC構成（NIC2枚挿し）構成が可能です。

※この手法は、移行元仮想環境がHyper-Vの場合はサポートされていません。Hyper-VでNIC2枚構成を希望される場合は、「Nutanix MoveでHyper-V環境におけるNIC2枚挿し構成について」を参考にしてください。

セカンドNICを搭載した際、Moveアプライアンスの初期ウィザードでは設定内容としてあがってきませんので、手動で設定を行う必要があります。
今日は、セカンドNICの設定方法をお伝えします。

今回の環境は、Move 3.5を利用します。Move3.0.2以前の場合は一部の手順が異なりますのでご注意ください。
（なお、この手法は移行元ハイパーバイザーがHyper-Vの場合はサポートされていませんのでご注意ください）

まずは、「AHVへの引っ越しは、Nutanix Moveで（その３）」を元に、Moveアプライアンスを展開します。
Move 3.5現在、Moveアプライアンスの展開先は、AHVでもESXiの2つが選択可能です。

展開し、初期のNIC設定が終わった後、一度Move仮想アプライアンスをシャットダウンします。
その後、Move仮想アプライアンスにNICを追加し、再度Move仮想アプライアンスを起動します。

 

起動後、adminユーザーでMoveアプライアンスにログインを行います。

ログイン後、rootユーザーにスイッチします。

rs

※パスワードは、デフォルト「nutanix/4u」です。

ここで、初期に付与したNICと新たに追加されたNICの状態を確認します。

ip addr | more

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast state UP qlen 1000    #新しく追加したNIC
    link/ether 50:6b:8d:2c:e2:10 brd ff:ff:ff:ff:ff:ff
    inet 192.168.XXX.YYY/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::526b:8dff:fe2c:e210/64 scope link
       valid_lft forever preferred_lft forever
3: eth1:  mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 50:6b:8d:a2:d1:a3 brd ff:ff:ff:ff:ff:ff
4: docker0:  mtu 1500 qdisc noqueue state DOWN
    link/ether 02:42:0d:fe:93:43 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
5: br-4dd6ea78bbf6:  mtu 1500 qdisc noqueue state UP
    link/ether 02:42:e1:d3:47:34 brd ff:ff:ff:ff:ff:ff
    inet 172.18.0.1/16 brd 172.18.255.255 scope global br-4dd6ea78bbf6
       valid_lft forever preferred_lft forever
    inet6 fe80::42:e1ff:fed3:4734/64 scope link
       valid_lft forever preferred_lft forever
7: veth80212f5@if6:  mtu 1500 qdisc noqueue master br-4d
d6ea78bbf6 state UP
  

eth2が新たに追加されたNICであることがわかりますので、それを控えておきます。

続いて、/etc/network/interfaceを開きます。

vi /etc/network/interface

# Configured by /opt/xtract-vm/bin/configure-static-ip at Sat Oct  5 04:12:31 UTC 2019
# loopback configuration
auto lo
iface lo inet loopback

# eth0 Static IP configuration
auto eth0
iface eth0 inet static
        address 192.168.XXX.YYY
        netmask 255.255.255.0
        gateway 192.168.XXX.ZZZ

既存で初期に設定した、IPアドレスが設定されていますので、した側に以下のように設定を行います。

DHCPでIPを付与する場合

auto eth1
iface eth1 inet dhcp

固定IPアドレスを付与する場合

auto eth1
iface eth0 inet static
        address 172.16.XXX.YYY
        netmask 255.255.255.0
        gateway 172.16.XXX.ZZZ

ここで注意点ですが、デフォルトゲートウェイは1つのインターフェースにしか付与できません。
そのため、gateway項目は、eth0かeth1のどちらかにしか記載してはいけません。

それぞれに経路設定が必要な場合は、static routeを設定する必要があります。

入力後は、ネットワーク設定を再起動し新しい設定を読み込みます。

service networking restart

root@move on ~ $ service networking restart
 * WARNING: you are stopping a boot service
 * WARNING: you are stopping a boot service
 * Stopping busybox ntpd ...                    [ ok ]
 * Stopping networking ...
 *   eth0 ...                                   [ ok ]
 *   lo ...                                     [ ok ]
 * Starting networking ...
 *   lo ...                                     [ ok ]
 *   eth0 ...                                   [ ok ]
 *   eth1 ...
 * Starting busybox ntpd ...                    [ ok ]
root@move on ~ $

このような感じで、ネットワークサービスが再起動できていれば問題ありません。

再度、ipaddrコマンドでIPがNICに付与されているかを確認します

ip addr | more

root@move on ~ $ ifconfig | more
br-4dd6ea78bbf6 Link encap:Ethernet  HWaddr 02:42:E1:D3:47:34
          inet addr:172.18.0.1  Bcast:172.18.255.255  Mask:255.255.0.0
          inet6 addr: fe80::42:e1ff:fed3:4734/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7181 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6586 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:8082154 (7.7 MiB)  TX bytes:7393655 (7.0 MiB)

docker0   Link encap:Ethernet  HWaddr 02:42:0D:FE:93:43
          inet addr:172.17.0.1  Bcast:172.17.255.255  Mask:255.255.0.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr 50:6B:8D:2C:E2:10
          inet addr:192.168.XXX.YYY  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::526b:8dff:fe2c:e210/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:26937 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7973 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:8926408 (8.5 MiB)  TX bytes:5183056 (4.9 MiB)

eth1      Link encap:Ethernet  HWaddr 50:6B:8D:A2:D1:A3
          inet addr:172.16.XXX.YYY  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::526b:8dff:fea2:d1a3/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10513 errors:0 dropped:0 overruns:0 frame:0
          TX packets:323 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:793805 (775.2 KiB)  TX bytes:3130560 (2.9 MiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

ただしく、eth1にIPが付与されていることが分ります。

続いて、iptablesの停止とDocker Serviceの再起動を行います。

service iptables stop
svcstop
service docker restart
svcstart

eth1から、MoveのUI画面を開くことも出来ますが、eth0を利用してNutanixクラスターのターゲットストレージコンテナをマウントするため、Nutanixクラスターのインターフェイスは、eth0に向けておくことが必須となります。

これで、Nutanixと既存の移行元環境が別のネットワークであってもMove仮想アプライアンスを介して、移行を行うことが可能です。

Nutanix Move 3.5の紹介とテスト機能について

Nutanix Move 3.5が2020年4月末に公開されました。

今回のバージョンでは、バグフィックスの他に新たな機能が追加されました。

今回は新しい機能について紹介したいと思います。

＜新機能＞

• AWS環境からNutanix ESXi環境への仮想マシン移行がサポートされました。
• 仮想マシンの完全な移行の前に、ターゲット環境で移行テスト機能が追加されました。
• VMware vSphere 6.7 Update3 の対応
• ESXiからAHVへの移行対象ゲストの追加
  (RHEL 6.10 /CentOS 7.5～7.7/Windows Server 2019)

AWS環境からESXiへの移行は、読んで字のごとくです。
大きな点は、本番移行前にテスト機能が搭載されたことだと思います！

今回は、このテスト機能について、もう少し深く見ていきたいと思います。

Nutanix Moveで移行をする際によく言われるのは、もし失敗したら？という不安と、それを払拭するためのテストです。
失敗しないのか？という点については、どこについて失敗する可能性があるかを考える必要があります。
Nutanix Moveは、vSphereのバックアップ時に利用するAPI(VDDK)を利用して、仮想マシンイメージのスナップショット差分を取得することで、移行元の仮想マシンはパワーオンのまま仮想マシンを移行する仕組みを持っています。この場合、失敗する可能性があるとすれば、MoveアプライアンスとESXiとの疎通(ネットワーク)の問題であったり、スナップショットが既に大量にあり、VDDKのイメージの取得に失敗するなどいろいろな要因が考えられるため、簡単に失敗するしないという話の前に、Moveの仕組みを知った上で考慮点を洗い出すことが大事だと思います。

話がそれましたが、では実際に正しく動くかテストをしたいという希望に対して、Nutanix Moveは、移行に失敗しても元の仮想マシンは残っていますので、再度元の仮想マシンを起動することでサービスを継続することは可能です。しかし事前のテストのタイミングで、本番の仮想マシンが一時的であってもシャットダウンされてしまうのは、作業を行う時間も限られてしまいますし、あまりスマートではありません。

今まで、Moveを利用したいと言われる方でテストをしたいという要望を言われた場合、元の仮想マシンをクローンしてもらい、それをMoveで移行できるか試してくださいという形で案内をしておりました。元の仮想マシンには何の変更も入れることが無くテストを自由な時間で行うにはおそらくこの方法をとるのが良いかと思います。

一方で、Nutanix Moveに新たについたテスト機能は、実際に稼動している仮想マシンのデーターを移行しつつ、今移行しているデーターを元にその仮想マシンが、Nutanix上で正しく稼働するかをテストすることができます。この段階でテストで正常動作しないことが分れば、一度その移行ジョブを取り消し原因を調査する必要がありますが、本番の仮想マシンを停止すること無く判断をすることが出来ます。

このテスト機能は、AHVからAWSの移行を除く組み合わせの全てをサポートしています。つまり、ESXiからAHV、Hyper-VからAHV、AWSからAHV、ESXiからNutanix+ESXiの環境であれば、このテスト機能が利用可能と言うことになります。

実際のMoveの画面を見ながら変更点を確認しましょう。

まず、Migrationジョブ作成画面で、移行後のNutanix側に登録されたVLAN選択画面の下に、テスト用のVLANを選択する画面が追加されています。こちらは、Target Networkで選択したVLAN以外しか選択できないようになっています。（移行先の本番VLANでテストは出来ない仕様になっているようです）

移行自体の動作は今までのバージョンと特に変わることはありません。

後変更となったところは、実際の移行画面となります。

あらたに、Test Actionというメニューが追加されています。このメニューには、「Create Test VM」、「Recereate Test VM」、「Remove Test VMの3つのメニューが用意されています。

初回テストは、「Create Test VM」を選択肢、まずテストで稼動を行います。

するとこのような形でメッセージが表示されます。移行元のVMに何も影響が無いことと、本来のMoveは、移行元の仮想マシンをシャットダウンして最終のスナップショットを取得しますが、これはテスト機能で稼動するため、クラッシュレベルでのスナップショットからの起動となる旨の注意点が記載されています。

テストが実行されると、View Test VMと言う形で、Prsimのリンクが表示されます。

Prism上を見ると仮想マシン名の末尾に「-MoveTest」という文字列が付与された仮想マシンが存在していることが分ります。
自動的にパワーオンされ、既に起動しております。

仮想マシン自体も、正しく起動していることが分ります。

なお、移行元の仮想マシンがパワーオフの場合、テスト後も仮想マシンはパワーオフのままとなります。
（移行元仮想マシンのパワーステータスに応じて、移行後の仮想マシンもパワーオン、パワーオフが判断されます）

テストが終わったら、仮想マシンはそのままで、Moveの画面から、「Remove Test VM」で、仮想マシンを削除します。

ちなみに、Test Actionで、Create Test VM実行中に、Cutoverボタンを押した場合、自動的にTest VMは削除され、カットオーバー処理が行われるようになっています。

なお、Cutover後のテストは当然ながら出来ません。

テスト機能は今までもなんとか回避は出来ていましたが、手間無く手軽に本番環境に影響なくテストが出来るというのは、移行に対するハードルが下がることに違いは無いと思います。

Nutanix Moveは、移行における大変便利な機能ですが、テスト機能などちょっとかゆいところに手が届く機能が増えて生きているのは、ユーザ視点であるNutanixの良さの一面を感じます。

Nutanix Moveのよくある質問とポイントをご紹介

Nutanix Moveは、すごく簡単に仮想マシンをNutanixクラスターに移行してくれるというのは、ご理解いただけたと思います。今回はNutanix Moveでよく聞かれる質問をご紹介したいと思います。

Q.Nutanix Moveは、どういう課金方法で提供されますか？

Nutanix Moveは、Nutanix Cluster（有償製品）を保有している場合、無償で利用することができます。Nutanix CEをご利用でNutanix Moveをご利用になりたい方もいるかと思いますが、現状Community版のNutanix Moveは提供されておりません。

Q.Nutanix Moveで移行がサポートされないゲストOSはどうすればいいのでしょうか？

Nutanix Moveは原則、AHVが対応しているゲストOSの大半をサポートしていますが、一部サポートされていないゲストOSやそもそもAHVが本来サポートしていないレガシーなOSをAHVで稼動させたい場合があるかも知れません。
Nutanix Moveは、既存ゲストマシンに対して、VMware Tools/WinRM等を利用してVirt IO Driverなどの必要なものをあらかじめインストールするなど、ほぼ全自動で移行が終えられるように作られています。サポートされていないOSの場合これらの事前準備時点でエラーが出てしまい、そのままでは移行することが出来ません。
この場合、事前にVirtI/O Driverなどの必要ドライバーを手動でインストール後、Nutanix Moveの移行時に、Preparation Modeを「Manual」に設定し、仮想ディスクのデーターだけをAHVのNutanixクラスターにデーター移行を行うことも可能です。
出来た仮想ディスクを元に仮想マシンを作成し、あとは必要な設定を入れれば移行を完了させることが出来ます。データー転送だけ異をNutanix Moveにお任せする機能を使うだけでもファイル移動に比べて大幅に減らす事が出来ます。

Q.Nutanix Moveの仮想アプライアンスは、AHV側に立てた方がいいのでしょうか？それとも旧環境の3Tier環境に入れれば良いのでしょうか？

Nutanix Moveは、ネットワークを通じて既存クラスターのデーターをvSphereの場合はVADPを使って取得し、NutanixクラスターのストレージコンテナをNFSでマウントしデーターをマウントしたストレージコンテナに配置をします。
いわゆる仮想環境におけるバックアップとおなじ考え方でデーターを取得します。
この場合、既存3Tier環境とNutanixクラスターの間のネットワーク帯域を比較して配置するのがよいと思います。
3Tier環境とNutanixクラスターの間が10Gのネットワークで接続されている場合、3TierでもNutanixクラスターでもどちらにMove仮想アプライアンスを立てても速度に変わりは無いと思います。一方、3Tier環境とNutanixクラスターの間が1Gで接続されている場合は、Nutanix環境に配置すれば、バックアップデーターをNutanixに配置する際は、CVMとダイレクトに通信が出来る環境になるため、高速にバックアップデーターを配置できるようになります。

Q.Nutanix Moveを利用するにあたって注意することは何かありますか？

ゲストOSを移行するにあたっては以下のことを確認することが大事です。

• 対応しているハイパーバイザーのバージョンを確認
  （ESXi5.1/Hyper-V2012～）
• 対応しているゲストOSの確認
  （既にOSメーカーがサポートを終了したOSは原則非対応）
• VMware Toolsがインストールされていること
• OSのAdministrator / root権限のアカウント情報がわかること
• Windowsの場合、UACがオフになっていること

とくに、UACが向こうになっているかのチェックは、忘れがちですがこれは無効かしておかないと、VMware Toolsなどのツール経由で必要なファイルをゲストVMに送った後、インストールスクリプトが実行されますが、そこでUACの確認画面が裏で表示され、制御ができないため、途中で処理が中断してしまいます。

▼ゲストVMを移行前にUACは"通知しないに"しておきましょう

Q.vCenter Serverが存在しない単独のESXiホストの仮想マシンは移行できますか？

Nutanix Move 3.2以降で、ESXi単独環境でvCenter Serverが存在しない環境でもNutanix Moveを利用することができます。ただし、VDDKのAPIを利用する関係からESXiのライセンスがvSphere Hypervisor（無償ライセンス）では、Moveを使った移行は対応していません。

Q.3TierのvSphere ESXiの環境からNutanix+ESXiの環境移行で利用できないですか？（Nutanix Moveの移行先はAHVのみでしょうか？）

Nutanix Move 3.3から、移行元vSphere(ESXi)環境から、Nutanix+ESXiの環境においても、仮想マシンの移行が出来るようになりました。従来は移行元のvSphere環境からNutanixのストレージコンテナをNFSでマウントしてストレージvMotionなどを使って、ストレージを移行することで、仮想マシンの引っ越しを実現していました。
しかし、既存vSphere環境を触りたくない（設定変更が許されない）場合もあるかと思います。そういった場合に、Nutanix Moveを利用することで、既存のvSphereからNutanix+ESXi環境への仮想マシンの引っ越しを、短いダウンタイムで行うことが出来ます。なお、ESXiからESXiへの引っ越しとなるため、Driver等のツールの流し込みはなく仮想ディスクファイルの引っ越しのみの動作となります。


以上、Nutanix Moveについての注意点やよくある質問をまとめました。
Nutanix Moveは無償で提供されていますが、大変よく出来たツールだと思います。
従来のV2Vにおけるダウンタイムに比べ圧倒的にダウンタイムを短くすることが出来ますので、仮想マシン移行の際は是非活用をおすすめします。

AHVへの引っ越しは、Nutanix Moveで HyperV編（その２）

前回までに、Moveを使って仮想マシンの移行準備を行いました。
今回は、実際に仮想マシンをAHVにマイグレーションします。

移行前に、Hyper-V上でデスクトップにファイルを作成しておきましょう。

では、Moveの画面にいき、仮想マシンにチェックを入れCutoverボタンをクリックします。

カットオーバーを行うと、仮想マシンがシャットダウンされ仮想NICの接続が切断される旨が記載されています。このまま「Continue」をクリックします。

イベントログを見ているとチェックポイント処理が行われ最終のスナップショットが送られていることが分かります。

既に移行処理が完了していると出ていますので、Prismで確認をします。

移行前に作成したファイルもきちんとデスクトップ上に存在しています。
また、デバイスドライバーもきちんとVirtI/O Driverになっていることが確認できます。

Hyper-Vであっても、vSphere同様に簡単にAHVに移行が出来ました。

今回のポイントは、Hyper-V第２世代仮想マシンの移行ということです。
Hyper-V第２世代の仮想マシンは、 UEFIで作成されており従来のImage Serviceを使ったVHDXの変換だけではAHV上で仮想マシンを動かすことが出来ない状況でしたが、Nutanix Moveを利用すると、UEFIのまま仮想マシンを移行させることが出来ます。
AOS5.11から、UEFIに正式に対応しましたので、Hyper-V第2世代の仮想マシンを移行する場合は、AOS5.11移行の環境を原則用意頂くことになります。
（AOS5.10であっても仮想マシンに対してUEFIモードで起動させることは出来ますが、原則サポータブルではありません）

▼第2世代の仮想マシンを移行すると、AHVの仮想マシンも自動的にUEFIに設定される。

以上、Hyper-V環境でのNutanix Moveを使った移行方法のご紹介でした。

AHVへの引っ越しは、Nutanix Moveで HyperV編（その1）

前回までに、ESXiからAHVへの移行が簡単にかつ、ダウンタイムをかなり短く行うことが出来ることが分かりました。
では、今回はHyper-VからAHVへの仮想マシン移行についてご紹介します。

今回は、Nutanix Move 3.4を利用して作業を行います。
移行元環境は、Windows Server 2012R2で、第2世代の仮想マシン対応で構成された環境にWindows Server 2012 R2をインストールした仮想マシンを移行します。

まずは、Nutanix MoveのSourceにHyper-Vを登録します。

すると、add the environment と表示されしばらく待ちが発生します。
このタイミングでHyper-Vホスト側にWinRM機能を利用して、MoveのAgentがインストールされます。インストール場所は、上記のSourceを登録する際のユーザープロファイルの配下にできあがります。この環境は、Administratorで登録をしていますので、「C:\Users\Administrator\Nutanix\Move\3.4」になります。
併せて、「move-service.exe」 が、「Nutanix Move Agent」という名前でサービスに登録されます。

なお、Move3.2までは、このAgentが日本語版のWindowsですとうまくインストールが出来ませんでした。これは、インストール時に利用しているPowerShellのコードが日本語に対応していないことに由来していましたが、Move3.3.1以降では、問題なく日本語環境でもインストールが可能です。

もし、Agentのインストールに失敗し、Sourceの登録に失敗した場合、Agentを手動でHyper-Vホストにインストール後、再度Source登録することで成功する可能性が高いです。
Agentバイナリは、Moveアプライアンスにhttp経由でアクセスします。

http://<nutanix-move-ip>/downloads/agents/move-agent-installer.exe

ダウンロードしたバイナリを、Hyper-Vホストにインストールします。

なお、インストール時には以下のパラメーターを入力します。

move-agent-installer.exe -o install <nutanix-move-ip> -u Administrator

最後のAdministratorは、サービスを起動するユーザーに紐付きますので、Administratorと書きましたが、実際には管理者権限を保有したユーザーとなります。

なお、AgentをインストールするとWindows Firewallにて、8087番のポートが開放されるルールが追加されます。このポート番号は、MoveとAgentがやりとりするために利用され、ポート番号を変更することはできません。

では、続いて、マイグレーションプランを作成します。

続いてソース環境とターゲット環境のNutanixを登録します。

続いて、移行したい仮想マシンの「＋」マークをクリックし、移動対象のVMに登録します。ここで！マークが表示されます。
この内容は、セキュアブートに関する注意事項です。
第2世代の仮想マシンでは、カットオーバープロセス中及びカットオーバーが完了するまでは、仮想マシンのセキュアブート機能は無効になります。カットオーバープロセスが終了すると、セキュアブート機能が再び有効化されます。

▼Hyper-Vで第2世代仮想マシンを作成するとデフォルトでセキュアブートが有効になる

セキュアブートは自動的に無効にされ、移行終了後にHyper-V側のソース仮想マシンは元の設定に戻りますが、セキュアブートが必要でない場合はあらかじめチェックを外しておいてもよいかと思います。なお、セキュアブートの無効化は該当の仮想マシンがパワーオフ状態の時のみ設定変更が可能です。

続いてネットワークのマッピングを行います。
ここで出てくるにSource Networkは、Hyper-Vホストのアダプタになります。
割り当てるネットワークは、仮想マシンが通信したいネットワークになります。

この画面では、vSphere同様、ゲストOSへVirt IO Driverをインストールするためのcredential情報の入力を行います。vSphereの場合同様複数の仮想マシンを一括して移行する場合、仮想マシン個別のcredential情報を入力することも可能です。

また、Move 3.4からタイムゾーンの設定項目も追加されました。
ここでは、「Asia/Tokyo」を選択します。

Hyper-Vの仮想NICに付与されたMac Addressをを引き継ぐ場合は、「Retain MAC Addresses form the Source VMs.」にチェックを入れます。

最後にサマリーを確認し、「Save and Start」をクリックします。

これで、Hyper-Vの仮想マシンにVirtI/O Driverなど必要なモジュールが、「C:\Nutanix」に配置されます。

Hyper-Vマネージャーで確認すると、vSphereと同様にチェックポイント（スナップショット）が順次取得されているのが分かります。

 では次回に実際に、カットオーバーを行いAHVへの移行を行ってみましょう。

AHVへの引っ越しは、Nutanix Moveで（その５）

前回までに仮想マシンの移行準備は完了しました。
では、実際に仮想マシンをマイグレートしたいと思います。

まずは、vSphereのスナップショットを見てみましょう。
一段階目のスナップショットは既に転送済みで、２回目以降のスナップショットが送信されています。
▼２回目のスナップショット

▼３回目のスナップショット

このスクリーン書ととを見ると分かるようにスナップショットは１０分に一度送られていますが、スナップショットが多段になってI/Oスピードの低下や仮想ディスクファイル破損を防ぐため、スナップショットは２段階までとなっており、順次古いスナップショットが新しいスナップショットを作成される際に削除されます。

では、データーの差分がちゃんと送られているかを確認すするため、移行する前に、移行元のWindows Server 2012 R2の仮想マシンにファイルを作成してみます。

この検証は12/1に行っておりますのでその日付と時刻をテキストファイルに書いてデスクトップに保存します。

続いてMoveの画面で、In Progressをクリックし、Windows Server 2008 R2をCutover処理を行います。

確認処理が走ります。

vSphere Clientを確認すると、移行元の仮想マシンは、シャットダウンスされ最終のスナップショットが送られていることが分かります。

移行作業が完了すると、自動的にPrism上に仮想マシンが登録され、移行された仮想マシンが自動起動します。

Prismを見ると仮想マシンが登録され起動していることが分かります。

仮想マシンにログインすると、先程vSphere上で作成した仮想マシンにも移行前最終で作成したテキストファイルがきちんと移行されていることが分かります。

今回はNutanix Moveの動きと共に移行方法を紹介しましたが、ユーザー側で操作することはMoveの画面で移行元と移行先を選択するぐらいで面倒な作業無く、任意のタイミングで切り替えが出来るというのは大変便利であることがわかります。

AHVへの引っ越しは、Nutanix Moveで（その４）

前回まででNutanix Moveの基本設定が終わりました。
では実際に、Nutanix Moveを使って仮想マシンを移行の設定をご紹介します。

まずは、Moveの管理画面の真ん中にある「Create Migration Plan」で移行の計画を作成します。

まずは、MigrationPlan名を入力します。

続いて、移行元のハイパーバイザーと移行先のNutanixクラスター、移行先のストレージコンテナを選択します。

ESXiに登録されている仮想マシンの一覧が表示されます。
移行対象にしたい仮想マシンの「＋」マークをくり行くすると、右側の移行対象一覧にと登録されます。
ここでは、ESXi5.1に登録されたWindows Server 2008R2とWindows Server 2012 R2の2台の仮想マシンを移行します。（仮想マシンインベントリ名表示がすべて入りきれていませんが、マウスポインタを当てると名称がフルで表示されます）
選択完了後、「Next」をクリックします。

続いて、移行先環境のVLANを選択し、Nextをクリックします。

続いて移行の詳細設定情報が出てきます。ここから紹介するオプションは非常に重要です。

Preparation Mode

こちらは仮想マシンの移行方法についてです。
Auto
Virt I/O Driverや移行ツールを移行対象の仮想マシンに自動インストールを行います。
Manual
本来Autoで実行される内容を、スクリプトで表示を行います。手動で移行元仮想マシン上で指定されたスクリプトを実行することで、Autoと同じ状態にすることが出来ます。
Mixied
上記の2つを混在させる場合に利用

Credentials for VMs

こちらは、ゲストOSの管理者アカウントを入力します。
こちらのテキストボックスに入れた場合、プランに登録されている仮想マシン一括でこのcredential情報を利用します。
仮想マシン個別でcredential情報を入力したい場合は、「Override individual VM settings」で個別設定を行います。

Retain MAC Address from the Source VMs.

移行元仮想マシンのMACアドレスを維持します。
（MoveはIPアドレスを引き継ぎますが、このチェックを入れた場合は複数NIC搭載された仮想マシンにおいてもIPアドレスの引き継ぎが正常に動作します）

Bypass Guest Operations on Source VMs.

このオプションにチェックを入れると、ゲストVMにDriver等の必要な情報を一切投入せず素のままの仮想マシンの仮想ディスクを移行します。（あらかじめVirt I/O Driverを移行もと仮想マシンに入れている場合などに選択）

上記2つのオプションは、Manage Settings for Individual VMsで仮想マシン個別に設定が可能です。

Schedule Data Seeding

データーの移行を開始する日時を指定します。チェックを入れない場合原則プラン保存後から開始されます。

設定が完了したら「NEXT」をクリックします。

Nextをクリックすると、移行元仮想マシンにスクリプト等必要なファイル等が送信出来るか確認が行われます。（credential情報が間違っている場合この時点でエラーが発生します）

vSphere Clientから見ると、VMware Toolsを経由してファイルを転送いているところが分かります。

最後にサマリーが表示されます。
Planを保存しこの時点での実行をしない場合は、Saveを、このままPlanをスタートする場合は「Save and Start」をクリックします。

Planが正常にスターとするとPlan一覧が表示され、実行中の時は「In Progress」が表示されます。

In Progressをクリックすると、進捗状態が確認出来ます。

最初はDriverのインストールを行っていることが分かります。

Driverインストールなどの下準備が終わるとデーターの移行が開始されます。

vSphere上では最初にVMware Toolsを経由したファイル転送が行われていることが分かります。
移行元仮想マシンで認証したアカウントのTempディレクトリに必要なドライバー等が送信されていることが分かります。

Driverのインストールが終わると、スナップショットが取得され読み取り専用仮想ディスクが読み出されていることが分かります。

スナップショットマネージャーを確認すると、Move用のスナップショットが取得されていることが分かります。

あとは、データーの移行を待つばかりです。
初期データー我の移行が終わると、カットオーバー（切り替え）準備完了状態になります。Cutover可能な状況になるとStatusの横に●表示が付きます。

もうここまで来れば準備はほとんど完了しています。
では、次回いよいよ仮想マシンの移行完了までご紹介したいと思います。