2020年の振り返り

今年も残すところあと数日となりました。
Advent Calendar的には今日は最終日となりますので、一応年内最終記事（の予定）ということで、2020年を振り返ってみたいと思います。

2020年1月

日本初？ProLiant DXの動作検証を行う。

• Nutanixに新しい仲間　HPE DXシリーズのご紹介
• HPE DXシリーズ・実機レポート

2020年2月

案件対応でほとんど出張な日々だったが、月末に急に出張禁止になる

2020年3月

ベトナムの出張予定もなくなり、おうちでPrismを触る日々を過ごす

2020年4月

Nutanix FoundationすらもZoomで行うのが当たり前の日常になる。

2020年5月

前々から使っていたNutanix Collectorを紹介。以後、結構サイジングの際の標準ツールとして知名度が上がる。（と私は思っている...）

• 面倒なサイジングを楽にする「Nutanix Collector」の紹介

2020年6月

日々案件の対応に追われる・・・

2020年7月

Nutanix Clusters on AWSの検証を行う

2020年8月

オンラインでのセミナー対応が本格化
Meetup 2020.8で、Nutanix Clusters on AWSをご紹介

• Nutanix Clusterが実現する、勉強いらずのハイブリッドクラウド (2020/8 Nutanix　Meetup)

2020年9月

Nutanix .NEXT Digitalに参加、日々昼夜逆転の生活を行う。

2020年10月

案件対応に日々追われる・・・

2020年11月

久々に県外に環境構築のため出張・・・

2020年12月

NTC2021の称号を頂く（NTC更新）
Advent Calendarの記事に日々追われる。。。
今年は、2つのAdvent Calenderに投稿させて頂きました！

• West Nutanix NTC Advent Calendar 2020
• Nutanix Advent Calendar 2020

こう振り返ると要所要所で忙しいところは多々あったのですが、イベント毎で見るとなんだか、例年のように目立ったアクションは今年は少なかったというのが印象です。
個人的には、.NEXTがオンラインになり、さらには日本での.NEXT JAPANもなくなったことから、Nutanixの情報を得るイベントが減ったことで、例年よりNutanixの最新情報に触れることが少なくなり、ちょっと物足りない1年出会ったようにも感じます。

来年は、対面でのイベント毎が出来ると良いなと思いますし、来年はオンラインでもオフラインでもNutanixの情報を伝えていける機会を作られればと思っています。

AHVにおける仮想スイッチ（ブリッジ）の作成方法

AHV環境におけるAOS 5.19からPrism UIをとおして仮想スイッチの作成やアップリンクNICの設定変更、アップリンクNICのチーミングモードの変更が行えるようになりました。

AOS5.19は、STSのため次のLTSバージョンが出ればより多くの方のこの機能を利用していただくことができますが、新しいLTSが出るにはすこし時間がかかります。

現時点のLTSであるAOS 5.15においてAHV環境では、アップリンクの変更やブリッジの作成は、コマンドベースで行う必要があります。

今回は、新たなブリッジを作成する方法そして次に、アップリンクのNICチーミング方法の設定についてご紹介をしていきます。

仮想スイッチ（ブリッジの作成）は、AHV上で行います。なお、追加の仮想スイッチを作る場合は本番業務には影響はありませんが、アップリンクNICの操作間違いなどにより1ノードが疎通できなくなるとHAが発動する事象が出ることも考えられますので、アップリンクNICを含め操作する場合は、事前に仮想マシンを停止しクラスターサービスを止めておくことをおすすめします。

まずは、仮想スイッチを作成します。

manage_ovs --bridge_name br1 create_single_bridge

仮想スイッチ（ブリッジ）が出来たことを確認するため「manage_ovs show_bridges」を実行します。

$manage_ovs show_bridge
Bridges:
br0
br1 ★

続いて新たに作成したbr1のアップリンクモードを設定します。
bond-modeは以下から選択可能です。

bondモード	使用事例	上位スイッチ
active-backup	デフォルトの構成であり、推奨構成。 単一のアクティブなNICが全てのトラフィックを処理します。	通常ポート設定
balance-slb	各仮想NIC毎にアップリンクのNICが割り付けられます。 マルチキャストトラフィックの一部で問題が発生するため、推奨されていません。 接続する物理スイッチ側は、LAGの設定をしないで下さい。	通常ポート設定
balance-tcp	仮想マシンが通信するポート番号によって利用するアップリンクNICを割り付けます。 本機能は、接続する物理スイッチでLACPの設定を行って下さい。静的LAGモードは非サポートです。	LACP（動的）

現行ホストに存在しているNICを「manage_ovs show_interfaces」で確認します。

$ manage_ovs show_interfaces
name  mode  link speed
eth0  1000 True  1000
eth1  1000 True  1000
eth2  1000 False  None
eth3  1000 False  None
eth4 10000 False  None
eth5 10000 False  None
eth6 10000  True 10000
eth7 10000  True 10000

ここでは、eth4とeth5のNICを割り付けます。eth4とeth5は、まだリンクアップしていない状態でアップリンクの設定をするため「--require_link=false」を付与します。

なお、既存で用意されているデフォルトの仮想スイッチ（br0）においてアップリンクモードを変える場合も以下のコマンドを利用します。

manage_ovs --bridge_name br1 --interfaces eth4,eth5 --require_link=false --bond_mode=active-backup update_uplinks

では、アップリンクNICと仮想スイッチ（br1）の状態を以下のコマンドで確認していみます。

$manage_ovs show_uplinks
Bridge: br0
  Bond: br0-up
    bond_mode: active-backup
    interfaces: eth7 eth6 
    lacp: off
    lacp-fallback: false
    lacp_speed: slow
Bridge: br1
  Bond: br1-up
    bond_mode: active-backup
    interfaces: eth4 eth5 ★
    lacp: off
    lacp-fallback: true
    lacp_speed: off

これで作業は完了です。続いて、VLANの作成を行います。
AOS5.19より前の環境においては、複数の仮想スイッチを作成した場合、VLAN作成は必ず「acli」で作成を行って下さい。これは、PrismのVLAN作成画面ではどの仮想スイッチに対してVLANを作成するかの指定が出来ないためです。
ここでは、VLAN20のネットワークを新しく作成したbr1側に作成したいと思います。

acli net.create vlan20-seconde-net vlan=20 vswitch_name=br1

重要な点は、vswitch_nameを定義することです。

以上で、作業は完了です。PrismのNetwork Visualizationの画面で見ると新しい仮想スイッチ（ブリッジ）が作成されNICがアップリンクに割り当たっていることが分ります。

作業における注意点は以下の通りです。

• アップリンクNICを変更することでノード間疎通が出来なくなるとトラブルが発生することが予見されます。あらかじめホストをメンテナンスモードにするかクラスターサービスの停止を行った上で作業を行って下さい。
• manage_ovsは、操作を行ったCVMのホストにのみ反映されます。クラスター内の全てのノードに対して作業を一括で行うためには、「hostssh "manage_ovs ～」と、hostsshで各ホストに実行を行って下さい。
• manage_ovsは、クラスターメンバーに属していないノードでも作業が可能です。クラスターに新規で追加を行うノードに対してmanage_ovsでアップリンク設定を変更した上で、ノード拡張を行うことが可能です。
• AOS5.1までで利用していた、ovs-vsctlコマンドによる仮想スイッチ作成は、AOS5.5以降サポートされていません。

本項目では、manage_ovsコマンド出の作業方法をお伝えしました。acliで、「net.create_cluster_vswitch」を利用すると、各ノードをローリングでメンテナンスモードのしながらアップリンクNICの設定を変更できます。（当然ながらクラスターサービスが起動している状態で実施）

この「net.create_cluster_vswitch」は、AOS 5.19からは「net.create_virtual_switch」コマンドに変更されており、Prism側の仮想スイッチ作成オペレーションと紐付いた操作が可能となっております。

AOS5.0時代に比べるとAHVにおける仮想スイッチの操作はだいぶ楽になっていますが、ovs-vsctlコマンドでの操作が廃止になったり、acliでの仮想スイッチ操作がコマンドが変更になったりとかなり時代に応じて変更されています。

AOS5.19以降はPrismからの操作が最も楽な方法かと思いますが、次のLTSバージョンがリリースされるまでは、現行のLTSであるAOS 5.15の利用においては今回ご紹介したコマンドベースでの作業となります。（次のLTSが待ち遠しい物です）

AOS 5.19アップデート（その2）AHV環境における仮想マシンのストレージコンテナ移動

AOS 5.19で搭載された機能の1つで、AHV環境における仮想ディスクのストレージコンテナ間移動機能があります。vSphereにおいては、vSphere Standard以上で、Storage vMotionという機能を利用することで、仮想マシンを稼動したままDatastore間の移動ができます。

Nutanix + vSphere ESXiの組み合わせにおいても、Storage vMotionは利用可能です。一方で、Nutanix ＋ AHV環境においては、仮想マシンを稼動したままストレージコンテナ間を移動する機能は、ありませんでした。AHV環境の場合、ストレージコンテナ間を仮想マシンが移動するユースケースとしては、元々RF2で稼動してた仮想マシンを、よりミッションクリティカルなRF3で稼動しているストレージコンテナに再配置したいなどのストレージポリシーが異なるストレージコンテナに仮想マシンを再配置したい場合に利用するぐらいで、ストレージのリプレース等で利用することはありませんので、そこまで必須という機能では無かったため、今までは仮想マシンを停止してImage Serviceを経由して仮想ディスクを複製するという形で対応をしていました。ただ、Image Serviceでの登録は、様々なパラメーターを必要とするため、簡単に移動という訳にはいかず、一手間かかる物でした。

今後は、Image Serviceを利用せずに仮想ディスクの移動が可能となります。

では、その手順をご紹介いたします。

まずはじめに、この機能はまだGUIでは搭載されておらず、acliを利用して行う必要があります。

コマンドは簡単です。「vm.update_container VM名 container=移行先のコンテナ wait=false」で移動できます。パラメーターとして「disk_addr_list=」を付けるとその仮想マシンに接続されている複数の仮想ディスクのUUIDを指定した仮想ディスクだけを移動対象にすることも可能です。この場合カンマ切りで複数の仮想ディスクを指定することも可能です。今回は「vDiskMove-VM」という仮想マシンを、「SECONDE-CONTAINER」というストレージコンテナに移動したいと思います。

vm.update_container vDiskMove-VM container=SECOND-CONTAINER wait=false

これだけで完了です。コマンドのみとはいえ、そこまでハードルの高いもではありません。

移行作業が開始されるとタスクの進捗を確認できます。

なお、仮想ディスクを移動する際には以下の注意点があります。

• 移動中は仮想マシンのクローン及びスナップショットの取得が出来ません
• 仮想ディスク移動中は、仮想ディスクコピーを行うため一時的にストレージの利用料が増えます。移動が完了すると使用容量は元に戻ります
• ProtectionDomainで保護されている仮想マシンは、移動できません。あらかじめProtection Domainの保護対象から除外する必要があります。
• Volume Groupで、仮想ディスクが直接SCSIでアタッチされている環境の場合、仮想マシンで利用しているVolume Group以外の仮想ディスクのvmdisk_uuidを指定する必要があります。

上記の事柄から、Volume Groupのストレージコンテナ移動は現状対応していません。従来通りImage Serviceを利用して移動する必要があります。

DataProtectionの除外設定は、Entitiesから移動したい仮想マシンを「Unprotect」で保護対象から外すだけで良いです。Local SnapshotsやSchedulesを削除する必要はありません。仮想ディスクを移動後に再びEntitiesに仮想マシンを再登録することで再保護が可能です。

ただし注意点としては、仮想ディスクを移動する前に取得したスナップショットは、移動前のストレージコンテナに保存されたままとなります。そのため、移動する前のスナップショットでリストアすると、スナップショットを取得した時点でのストレージコンテナにリストアされます。これは、Data Protectionで取得したスナップショットは仮想マシンがその時点で存在するストレージコンテナに保持されるためです。

また、もう一つの注意点は、DataProtectionのスナップショットでは無く、AHVの仮想マシンに対して取得できる「VM Snapshots」のスナップショットです。VM Snapshotsは保持したまま仮想ディスクの移動は可能です。しかしこのスナップショットも取得した時点でのストレージコンテナに保存されています。そのため、仮想マシンを別のストレージコンテナに移動後、移動前に取得したスナップショットをリストアした場合、スナップショットを取得した時点のストレージコンテナに戻ってしまいます。

今回は新たに追加された仮想マシンのストレージコンテナ移動機能について紹介しました。スナップショットの取扱いの注意点やVolume Groupがまだ未対応、acliでのみ操作可能など、まだ荒削りところはありますが、今までのImage Serviceでの操作に比べると大変楽に作業できると思います。

AOS 5.19アップデート（その1）AHV環境における仮想スイッチの作成方法

AHV環境において１つハードルが高いことは、仮想スイッチを複数利用する構成です。
結論から言えば構成は可能なのですが、従来AHVにおける仮想スイッチの作成は、CVM上から「manage_ovs」コマンドを実行し、環境を確認しながら、AHV上で「ovs-vsctl」コマンドで設定を行うという、あまりユーザーフレンドリーとは言えない状況でした。

そもそもNutanixおいては、シンプルな構成を目指していることと、NutanixのCVM間の通信がデーターローカリティーの概念により10Gネットワークをフルで利用することがないため、10GのネットワークにVLAN分離でサービス系とCVMのネットワークを混在して利用してもなんら問題がないため、そこまで大きな問題として顕在化することはありませんでした。

とはいえ、セキュリティの観点からアップリンクNICを意図的に分けたいなどの構成や設計の方針で仮想スイッチを分けなければいけないことがあるかと思います。

そんな仮想スイッチ作成作業ですが、AOS 5.19よりPrismの操作だけで、仮想スイッチに追加・削除ができるようになりました。

今日は、この仮想スイッチの追加機能について紹介いたします。

＜ブリッジと仮想スイッチについて＞

そもそもAOS5.18までは、AHVにおける仮想スイッチは、ブリッジという表現をしていました。しかし、AOS5.19でブリッジという表現は表上からは消えて「vs(Virtual Switch)」という表現に改められています。もちろんbr0という形で内部的にはブリッジとして動作しているので、表面上の表現だけが変更になりました。

▼AOS 5.15.4のNetwork Visualizationでのホストのネットワーク画面

▼AOS 5.19のNetwork Visualizationでのホストのネットワーク画面

＜仮想スイッチの作成方法＞

では、実際に2個目の仮想スイッチを作成していきましょう。
今回は、10Gのネットワークで利用しているbr0には割り当てられておらず、どこの仮想スイッチにも割り当てられていない、1GのNIC「eth3」と「eth4」のNICを「service-sw」という新たに作る仮想スイッチに割り当てたいと思います。

まずは、ギアアイコン→「Network Configuration」→「Virtual Switch」に移動します。
Foundation直後は、vs0として1つの仮想スイッチが見える状態になっています。

ここから、右上の「+ Create VS」をクリックします。

次に、仮想スイッチに必要なパラメーターを入れるウィザードが出てきます。
仮想スイッチ名、説明、MTUサイズ（1280~9216）を入力します。
Configuration Methodは、詳細な設定ができるよう「Standard」を選択します。
Quickは、各ホストをメンテナンスモードにせずホストを再起動します。ホスト自体はrollingでの再起動となりますが、時間短縮のためメンテナンスモードにせずホスト再起動を掛けるため、仮想マシンワークロードが稼動していると予期せぬ仮想マシンのパワーオフが実施されますので、仮想マシンがCVM以外に存在しない状況の場合のみ選択できます。

ここでは、「service-sw」と名称を設定します。

次に、アップリンクモードやアップリンクNICの設定ができる画面が表示されます。

BondTypeには、「Active-Backup」「Active-Backup with MAC pinning」「Active-Active」「No Uplink Bond」が選択できます。
No Uplink Bondは、チーミング指定なしということになります。通常のサーバー運用ではまず選択しないオプションになるかと思います。

Select Hostsは、設定反映するホストを指定します。こちらの機能はおそらくノード拡張後にボンドモードが既存クラスターと異なっている場合に利用する機能のようで、完全に新規の仮想スイッチを選択する場合、「All Hosts」を選択しないと、ウィザードの次の画面に行こうとすると「When creating/editing a virtual switch, all hosts must be selected (except storage-only node).」と表示されます。

続いて、新しく作る仮想スイッチに割り当てる物理NICを選択します。
ここでは、eth3と4を割り当てます。
このNIC選択は、ホスト毎に選択できますので、複数ホストある場合は、1ホストずつ別のNICを割り当てることも可能です。

ここまでパラメーターを入れたら、「Create」で仮想スイッチを作成します。

今回はQuickを選択していませんでしたが、稼動している仮想マシンが少なかったのもあり、3台のホストを再起動しても時間は20分かからないぐらいでした。

全てのホストの再起動が終わると、タスクが完了します。

完了後は、いつも通り「Network Configuration」→「+ Create Network」からVLANを作成します。

VLANの作成画面で、仮想スイッチの選択画面が出てきていることが分ります。
ここで、先程作成した仮想スイッチを選択し、VLANを作成します。

作成が完了したVLANは、そのままPrismのVirtual Machinesの画面から、仮想マシンに割り当て可能です。

Network Visualizationで確認してみましょう。

ホストを選択すると、先程作成した仮想スイッチとアップリンクNICが割り当てられていることが分ります。

Virtual Switch出先ほど作成したスイッチ「service-sw」をチェックを入れるとアップリンクNICの色が既存の仮想スイッチであるvs0とは別の色で表示されます。

＜仮想スイッチの削除方法＞

仮想スイッチの削除も、Virtual Switchの一覧から削除可能です。（既存で存在するvs0は削除できません）

以上で、仮想スイッチの作成方法は終わりです。

しかし、今までのあのコマンドと長いパラメーターを利用せず仮想スイッチを作成できるようになったのは、個人的には感動的な機能です。（というかもっと早く実装してほしかったというのが正直なところですが）

AHV利用時のハードルがまた一つ消えたことは、よりAHVが身近なハイパーバイザーに進化してきているという現れだと思います。

LCM2.4で発生する「SSL: UNKNOWN_PROTOCOL」について

AOS5.19のリリースと共に、LCM（Life Cycle Management）も2.4がリリースされました。

LCM2.4が自動アップデートされ、定期インベントリを回すように設定をしていると、インベントリの取得で失敗していることがあるかも知れません。

Tasksでインベントリの情報を見ると以下のようなイベント実行エラーを確認することが出来ます。

Operation failed. Reason: Repository Image Module Foundation failed with error: 'Exception Error occured getting data from https://download.nutanix.com/foundation/lcm-builds/repository_metadata/repository_metadata_v2.json: [SSL: UNKNOWN_PROTOCOL] unknown protocol (_ssl.c:618). Not fetching available versions for module: Foundation' while fetching available versions. Logs have been collected and are available to download on 192.168.XX.YY at /home/nutanix/data/log_collector/lcm_logs__192.168.XX.YY__2020-12-20_09-38-05.212878.tar.gz

このエラーは、LCM2.4にアップデートされたことで発生する事象です。

詳細は、KB:10475に記載があるとおり、HTTPで疎通をする際に問題であり、ワークアラウンドとしてHTTPで疎通をするようにと記載があります。

具体的には、LCMの画面で「Settings」ボタンを押し、「Enable HTTPS」のチェックを外して、Saveボタンをクリックします。

事象からしておそらくバグだとしか思えないのですが、今後のリリースで解消予定のようです。LCM2.4にバージョンアップしたら、新しい情報が入手できなくなった場合は、Tasksでエラーが出ていないかと、Enable HTTPSにチェックが入っていないかを確認してみてください。

AHV環境のネットワークチーミングについて

vSphereでは、標準スイッチと分散スイッチの2つのスイッチが構成できます。
Nutanix環境でvSphereを利用する場合は、どちらのスイッチ方式もvSphereのベストプラクティスに従って利用可能です。

一方、AHVにおける仮想スイッチは、Open vSwitchが実装されています。

今回は、AHVにおけるアップリンクNICのチーミングについてみていきたいと思います。

まず、AHV環境においては、仮想マシンとの疎通で利用できる1つの仮想スイッチ（ブリッジ）が作成されています。ブリッジはFoundationでイメージングをすると自動で作成されます。

AHV環境におけるアップリンクのボンディング（チーミング）は、デフォルトがActive/Backupで構成されます。

AHVにおけるアップリンクのチーミング方法は、以下の3つの方法があります。

<Active/Backup>

Nutanixにおける推奨設定になります。単一なアクティブNICを利用し、障害発生時にはBackupのNICに切り替わります。

<balance-slb>

仮想マシンのMACアドレスごとに、アップリンクNICが割り付けられます。単体の仮想マシンとしては、最大1NICの速度しか出ませんが、アップリンクのNICを最大限利用することができます。この場合、MACアドレスごとにNICが異なる疎通だけが行えますので、スイッチ側でLink Aggricationを構成する必要はありません。
balance-slbは、マルチキャストトラフィックで問題が発生することがありますので、構成は推奨されていません。

<LACP with balance-tcp>

LACPを利用し、TCPのポート番号ごとにアップリンクNICが割り付けられます。
LACPを利用するため、スイッチ側を静的LAGでの構成はしないでください。

アップリンクにおける注意点としては、以下の通りです。

• 異なる速度のNICでチームを組んではいけない。
  （アップリンクに1Gと10G NIC混在などはNG）
• 異なるベンダーのNICでチームを組んではいけない
  （intelのNICとMellanoxのNICでチームを組むなどはNG）
• LACPがどうしても必要という理由がない場合は、Active/Backupのロードバランシングを使用してください。
• AHVで、静的LAGを利用しないでください。

アップリンクモードの変更は、PrismのNetworkから設定変更が可能です。
ネットワークページの「+ Uplink Configration」をクリックします。

アップリンクのチーミングモードを変更し、Saveボタンをクリックすると、1ホストずつ設定変更が行われ、ホストが再起動します。（仮想マシンはライブマイグレーションされます）

次回はアップリンクのチーミングモード変更について、コマンドでの操作を紹介します。

AOS 5.19がリリースされました

2020年12月18日に、STSの最新版であるAOS 5.19がリリースされました。

今回もSTS版のためかなりの機能追加が含まれております。
今日は、実装された機能の中から実運用で利用できる機能を中心にご紹介いたします。

• Leap利用時のマルチサイトレプリケーション
  
  
• クロスクラスターライブマイグレーション
  Nutanixクラスターをまたいでの仮想マシンライブマイグレーションが対応になりました。この機能はLeapの延長線上にあり、対象の仮想マシンを保護対象にする必要があります。（当然ながらLeapなので、Prism Centralも必須です）
  
  
• ライセンスマネージャーの登場
  こちらは、ライセンス管理を行うPrismの画面が刷新されています。
  
  
• ストレージオーバーコミット表示の強化
  オーバーコミット時に閾値を設定でき、その閾値にあわせて表示の色が変わるようになりました。
  
  

なお、オーバーコミットにおける警告は、ユーザーごとに状況が異なるため、手動での設定となります。

• ROBOクラスターにおけるネイティブ暗号化機能のサポート
  
  
• Nutanix Flowにおけるマルチテナント対応（Tech Preview）
  こちらは、.NEXT Digitalでも発表があったVPCによる仮想ネットワークやVPN機能実装ですが、さっそくTech Previewとして実装されています（ロックされているようで特殊なことをしないと機能は有効化されないそうです...）
  
  
• FlowにおけるVDIポリシーの強化
  こちらは、Idenity Firewallルールの適用において、ユーザーログアウト時のFirewallルールが設定可能になりました。
  
  
• Prism Centralにおいて複数のSyslogサーバーに対応しました。
  
  
• AHVにおけるストレージコンテナ間でのライブマイグレーション
  これは、待望の機能です。AHVにおいては、仮想マシンがストレージコンテナ間を移動する際は、Image Serviceへの投入が必要であり、仮想マシンの停止も発生するため手間でかつ不便な点でしたが、こちらは解消となります。
  
  
• 仮想スイッチの設定がPrismで設定可能に
  従来は、構成をPrsimで見ることはできましたが、アップリンクNICの設定変更、VLAN作成以外（仮想スイッチの作成等）は、コマンドラインで行う必要がありました。
  AOS5.19からは、GUIで仮想スイッチの作成等柔軟なネットワーク構成がPrism Element上から行うことができます。
  これは、とても待ち望んでいた機能です！
  
  
• vGPUが割り当てられた仮想マシンのライブマイグレーションサポート
  こちらも望んでいた方が多い機能の1つでした。
  AHV環境においてVDI利用時などにおいて、仮想マシンのライブマイグレーションができるようになりました。

次回は、より詳細な機能紹介を行っていきたいと思います。

AHVでのOVAのインポート/エクスポートについて

NutanixでAHV環境におけるOVA対応は、今までもOVAファイルを展開して仮想ディスクファイル等を個別でインポートすれば、稼働させることができるという形で運用が可能でした。（OVAでパッケージングされていことにメリットがあるものを分解してアップロードするという時点でかなり無理やり感がありますが...）

一方でAHVで展開した仮想マシンをExportする機能は存在していませんでした。

しかし、Prims Central 2020.8以降、OVAの取り扱いができるようになりました。

今日は、仮想マシンのOVA/qcow2エクスポートとOVAインポートについてご紹介します。

操作には、Prism Centralを利用します、今回は、「Prism Central 2020.9.0.1」で確認を行います。

＜エクスポート方法＞

Prism Centralの仮想マシン一覧から、エクスポートしたい仮想マシンを選択し、Actionから、「Export as OVA」を選択します。

エクスポートの名称とQCOW2とVMDKのどちらの形式に知るかを選択し、Exportボタンをクリックします。

すると、Exportのタスクが作成されます。エクスポートボタンを押してもすぐにOVAファイルがダウンロードされるわけではありません。

次に、メニューから、「Virtual Infrastructure」から「OVAs」を選択します。

ここで、エクスポートされたOVAファイルが表示されます。（当然ながらエクスポート中のタスクが完了している必要があります）

ここから、先ほど選択したファイルをダウンロードします。

＜インポート方法＞

OVAのインポートは、先ほどの「Virtual INfrastructure」の「OVAs」の画面から行います。

ここで、インポートするクラスターおよび、OVAの名称を入力します。
Nameを入力せずに、OVAファイルを選択すると自動的にNameにOVAのファイル名が記入されそのままインポートが開始されます。

OVAファイルを選択する前にすべての項目を入れておかないと、OVAファイルを選択した時点ですぐにインポートが始まってしまいます。

アップロードが完了すると、一覧に表示されますので、そこからActionボタンから、「Deploys as VM」を選択します。

ここからウィザードで、仮想マシン名とスペックを設定できます。

次に、BIOS/UEFIの設定や、ディスク構成、ネットワーク構成を設定します。
ディスクの追加やNICの追加は、Attach Disk、Attach to Networkをクリックします。

OVAに設定されているNICに対してVLANを割り当てる場合、鉛筆マークをクリックしVLANの割り当てをおこないます。

最後に、PrismCentralで利用するカテゴリ（未記入可能）、タイムゾーンを設定します。cloud-initやsysprepを利用することもできます。

最後にレビューを行い、LaunchボタンをクリックするとDeployが開始されます。

OVAのデプロイが完了すると自動的に仮想マシンがパワーオンされます。

なお、OVAのインポート時、インポートしたファイルは、「SelfServiceContainer」ストレージコンテナの.ovaディレクトリ配下に保存されます。

OVAの取り扱いは従来すこしハードルが高いものでしたが、現在ではすべてマウス操作だけで簡単にインポート・エクスポートができるようになりました。
また、インポートしたOVAは、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枚構成で仮想マシンの移行が出来るようになりますので、困った際にはこの技も（必要に応じて）使ってみてください。

NGTによる仮想マシンの識別方法と証明書の更新方法について

前回は、仮想マシンクローン時の一括仮想マシンへのNGT設定情報アップデートの方法をお伝えしました。
そもそもこのngt_uuidは仮想マシン毎に個別で発行されますが、クローンする前の元の仮想マシンで利用したuuidに対してクローンした仮想マシンではNGTが有効にならない理由については触れていませんでした。もし発行されているuuidという識別だけであれば、クローン元の仮想マシンとクローン先の仮想マシンで同じuuidがngt_config.jsonに書き込まれているので、マスター仮想マシンがシャットダウンされていれば、クローンした仮想マシンでこのuuidは利用可能であると思いますが、実際にはこのクローンした仮想マシンでngtのステータスが有効になることはありません。前回の説明どうりNGTのISOをマウントし設定ファイルを更新する必要があります。

ではどのようにして仮想マシンそれぞれ固有の情報を識別しているかというと、それは仮想マシン毎に発行されるクライアント証明書に秘密があります。

Windowsの場合、ngt_config.jsonが配置されているディレクトリと同じ「C:\Program Files\Nutanix\config」配下に、「client-cert.pem」と「client-key.pem」ファイルがあることが分ります。これが各クライアント毎に生成される秘密鍵と証明書です。この証明書情報とその仮想マシンが疎通するIPアドレスから仮想マシンUUIDが識別され、Nutanix側で持っている仮想マシンUUIDに紐付く情報と一致しているかを見ています。

さてここで勘の良い方は気づいたと思います。

証明書ということは有効期限があります。証明書の有効期限が切れるとNutanixクラスターとNGTの間の疎通はできなくなります。

証明書の有効期限が近づいたら、またNGTのISOをマウントして仮想マシン再起動したらいいんでしょ？と思うかも知れませんが、現行AOS5.18のバージョンにおいては一度仮想マシンに対して証明書が発行されると、その情報が保持されたままとなり、この証明書情報を削除して再度生成するという手順を踏まないと有効期限を持った証明書が生成されません。

今回はこの証明書の更新方法について見ていきます。

わかりやすいように今回はWindows環境におけるNGT証明書の更新方法を紹介いたします。

Linuxなど別のOSや原則証明書更新方法の詳細は、KB:8120を参考にして頂くことをおすすめします。

＜現行の証明書の日付の確認＞

「C:\Program Files\Nutanix\config」の配下にある、「client-cert.pem」ファイルを確認します。このファイルをファイル名を「client-cert.pem.cer」に変更します。

拡張子を変更した、「clinet-cert,pem.cer」ファイルをダブルクリックすると証明書の日付を確認することが出来ます。

この証明書は、現時点で証明書の日付は切れていませんが、期限切れまで三ヶ月を切っています。今回はこの
確認後は、元のファイル名「client-cert.pem」にファイル名を戻しておきます。

＜証明書の更新＞

該当の仮想マシンが稼働するNutanixクラスターの任意のCVMにSSHで接続します。

仮想マシンのUUIDをncliを利用して取得します。（acliで取得しても構いませんが、vSphere環境のNutanixクラスターの場合「acli」が利用できませんのでここではncliを利用します。「ncli vm list name="仮想マシン名"」

ncli vm list name="Windows Server 2016 Template"

    Id                        : 00056d28-59d3-7bbc-0000-000000014005::20edafba-0644-4e57-a3cf-4abef2f69a5f
    Uuid                      : 20edafba-0644-4e57-a3cf-4abef2f69a5f　　★
    Name                      : Windows Server 2016 Template
    VM IP Addresses           : 192.168.1.91, 169.254.117.111
    Hypervisor Host Id        : 00056d28-59d3-7bbc-0000-000000014005::1591223829
    Hypervisor Host Uuid      : 92dad1eb-6562-4489-aca2-5e15ca07adc4
    Hypervisor Host Name      : NX-AHV-2
    Memory                    : 4 GiB (4,294,967,296 bytes)
    Virtual CPUs              : 2
    VDisk Count               : 1
    VDisks                    : 00056d28-59d3-7bbc-0000-000000014005::NFS:4:0:313
    Protection Domain         :
    Consistency Group         :

こちらのUUIDを元に、
「nutanix_guest_tools_cli delete_vm_tools_entity <UUID>」コマンドを実行し、証明書データーを削除します。

$nutanix_guest_tools_cli delete_vm_tools_entity 20edafba-0644-4e57-a3cf-4abef2f69a5f

2020-12-12 09:00:59,358Z:24911(0x7fa2ecb59a80):ZOO_INFO@log_env@960: Client environment:zookeeper.version=zookeeper C client 3.4.3
2020-12-12 09:00:59,359Z:24911(0x7fa2ecb59a80):ZOO_INFO@log_env@964: Client environment:host.name=ntnx-17sm6c100126-b-cvm
2020-12-12 09:00:59,359Z:24911(0x7fa2ecb59a80):ZOO_INFO@log_env@971: Client environment:os.name=Linux
2020-12-12 09:00:59,359Z:24911(0x7fa2ecb59a80):ZOO_INFO@log_env@972: Client environment:os.arch=3.10.0-1127.19.1.el7.nutanix.20201004.cvm.x86_64
2020-12-12 09:00:59,359Z:24911(0x7fa2ecb59a80):ZOO_INFO@log_env@973: Client environment:os.version=#1 SMP Sun Oct 4 12:55:45 UTC 2020
2020-12-12 09:00:59,359Z:24911(0x7fa2ecb59a80):ZOO_INFO@zookeeper_init@1008: Initiating client connection, host=zk3:9876,zk2:9876,zk1:9876 sessionTimeout=20000 watcher=0x556be811c6e0 sessionId=0 sessionPasswd=<null> context=0x7ffc5bf9bfc0 flags=0
2020-12-12 09:00:59,361Z:24911(0x7fa2ecace700):ZOO_INFO@zookeeper_interest@1954: Connecting to server 192.168.XX.YY:9876
2020-12-12 09:00:59,361Z:24911(0x7fa2ecace700):ZOO_INFO@zookeeper_interest@1991: Zookeeper handle state changed to ZOO_CONNECTING_STATE for socket [192.168.XX.YY:9876]
2020-12-12 09:00:59,361Z:24911(0x7fa2ecace700):ZOO_INFO@check_events@2191: initiated connection to server [192.168.XX.YY:9876]
2020-12-12 09:00:59,364Z:24911(0x7fa2ecace700):ZOO_INFO@check_events@2239: session establishment complete on server [192.168.XX.YY:9876], sessionId=0x1762179677dcf90, negotiated timeout=20000
2020-12-12 09:00:59,467Z:24911(0x7fa2ecb59a80):ZOO_INFO@zookeeper_close@3104: Closing zookeeper sessionId=0x1762179677dcf90 to [192.168.XX.YY:9876]

result_vec: kNoError

kNoErrorで終わっていれば、削除は無事に終了しています。

続いて、CVM上で「nutanix_guest_tools_cli create_vm_tools_entity <UUID>」コマンドを実行し、新しい証明書を作成します。

$ nutanix_guest_tools_cli create_vm_tools_entity 20edafba-0644-4e57-a3cf-4abef2f69a5f

2020-12-12 09:05:17,306Z:31766(0x7f33f5eaaa80):ZOO_INFO@log_env@960: Client environment:zookeeper.version=zookeeper C client 3.4.3
2020-12-12 09:05:17,306Z:31766(0x7f33f5eaaa80):ZOO_INFO@log_env@964: Client environment:host.name=ntnx-17sm6c100126-b-cvm
2020-12-12 09:05:17,306Z:31766(0x7f33f5eaaa80):ZOO_INFO@log_env@971: Client environment:os.name=Linux
2020-12-12 09:05:17,306Z:31766(0x7f33f5eaaa80):ZOO_INFO@log_env@972: Client environment:os.arch=3.10.0-1127.19.1.el7.nutanix.20201004.cvm.x86_64
2020-12-12 09:05:17,306Z:31766(0x7f33f5eaaa80):ZOO_INFO@log_env@973: Client environment:os.version=#1 SMP Sun Oct 4 12:55:45 UTC 2020
2020-12-12 09:05:17,306Z:31766(0x7f33f5eaaa80):ZOO_INFO@zookeeper_init@1008: Initiating client connection, host=zk3:9876,zk2:9876,zk1:9876 sessionTimeout=20000 watcher=0x565041b156e0 sessionId=0 sessionPasswd=<null> context=0x7fffe016f240 flags=0
2020-12-12 09:05:17,308Z:31766(0x7f33f5e1f700):ZOO_INFO@zookeeper_interest@1954: Connecting to server 192.168.XX.YY:9876
2020-12-12 09:05:17,309Z:31766(0x7f33f5e1f700):ZOO_INFO@zookeeper_interest@1991: Zookeeper handle state changed to ZOO_CONNECTING_STATE for socket [192.168.XX.YY:9876]
2020-12-12 09:05:17,309Z:31766(0x7f33f5e1f700):ZOO_INFO@check_events@2191: initiated connection to server [192.168.XX.YY:9876]
2020-12-12 09:05:17,320Z:31766(0x7f33f5e1f700):ZOO_INFO@check_events@2239: session establishment complete on server [192.168.XX.YY:9876], sessionId=0x1762179677dcf9f, negotiated timeout=20000
2020-12-12 09:05:17,423Z:31766(0x7f33f5eaaa80):ZOO_INFO@zookeeper_close@3104: Closing zookeeper sessionId=0x1762179677dcf9f to [192.168.XX.YY:9876]

result_vec: kNoError

同じくNoErrorで終わっていることを確認します。

続いて、Prism Elementから該当の仮想マシンのNGTのISOをマウントします。

なお、NGTのISOマウントはCVMから
「nutanix_guest_tools_cli mount_guest_tools <uuid> 」
で、マウントさせることも可能です。

「Nutanix Guest Tools Agent」サービスを先どうするか、仮想マシンを再起動します。

再起動後は、証明書の日付が新しくなっているか確認してましょう。
再度、「C:\Program Files\Nutanix\config」の配下にある、「client-cert.pem」ファイルを確認します。このファイルをファイル名を「client-cert.pem.cer」に変更します。

拡張子を変更した、「clinet-cert,pem.cer」ファイルをダブルクリックすると証明書の日付を確認することが出来ます。

変更したファイル名「client-cert.pem.cer」は、「client-cert.pem」に戻しておきましょう。（でないと証明書ファイルが読めずにNGTの疎通が出来なくなります）

あとは、NGTのコミュニケーションがただしく取れているかも確認しておきましょう。

$ ncli ngt get vm-id=20edafba-0644-4e57-a3cf-4abef2f69a5f
    VM Id                     : 00056d28-59d3-7bbc-0000-000000014005::20edafba-0644-4e57-a3cf-4abef2f69a5f
    VM Name                   : Windows Server 2016 Template
    NGT Enabled               : true
    Tools ISO Mounted         : true
    Vss Snapshot              : true
    File Level Restore        : false
    Communication Link Active : true

これで証明書の更新が正常に行い、NGTのコミュニケーションもNutanixクラスターと仮想マシン間で行えていることが分ります。

なお、証明書の有効期限が近づいた場合に何らかのアラートを表示する機能は、AOS5.18点ではまだ実装されていません。

今後のバージョンでこのあたりの仕様は変更になる見込みと聞いておりますので、今の間はNGTの証明書有効期限についてはすこし気に掛けて頂く必要があります。

Nutanix Guest Toolsを入れた仮想マシンのクローン方法

前回はNGTの構造について見ていきました。ngt_config.json内に仮想マシン毎に異なるUUIDが記載されるため、そのまま仮想マシンをクローンするとNGTがただしく疎通できないと言うことも紹介しましたが、クローンを行う際のNGTの取扱いについて紹介します。

マスターに仮想マシンにNGTをインストールを前もって行っておきます。

マスター仮想マシンか必要台数の仮想マシンをクローンします。

さて、ここまではよいのですが、ここからがちょっとしたコツが必要になってきます。

クローンした仮想マシンは、マスター仮想マシンのNGTの設定は一切引き継がれません。そのため、クローンした仮想マシンをPrismのMage Guest Toolsを見ると「Enable Nutanix Guest Tools」のチェックが外れていることが分ります。

いくらNGTが仮想マシンにインストールされていても、このチェックが外れていたらNGTは有効になりません。しかし、大量の仮想マシンに対してこのチェックを1台ずつ付与するのはかなりの手間がかかります。

ここで登場するのが、PrismCentralです。PrismCentralを利用すると複数の仮想マシンに対して一括でNGTの操作を行うことが出来ます。

本環境では2台のWindows Server 2019について動作確認をしていきます。
クローンした2台の仮想マシン「C:\Program Files\Nutanix\config\ngt_config.json」を確認すると2つの仮想マシンともngt_uuidが同じ値が記載されていることが分ります。

なお、選択する仮想マシンはパワーオンされている必要があります。
また、クローンした仮想マシンにそれぞれネットワークの設定が完了しており、Nutanixクラスターの仮想IPと疎通ができる環境状況にしておく必要があります。

仮想マシンを複数選択し、Actionから「Install NGT」をクリックします。

NGTをとおしてVSS連携やSSRを利用したい場合はチェックを入れます。
続いて、NGTインストール後のOS再起動をするかの確認は、「Skip Restart」を選択し、「Confirm & Enter Password」をクリックします。

続いてゲストOSのユーザー名とパスワードを入力する画面が出てきます。この画面では、ユーザーアカウントの情報は入力せず、「Skip and Mount」をクリックします。

すると、仮想マシンにNGTのISOがマウントされることが分ります。

ISOがマウントされたら、仮想マシンのOSを再起動します。
1台ずつ仮想マシンを再起動するのが面倒な場合は、Prism Centralを利用し全ての仮想マシンを一旦シャットダウンし再度パワーオンします。（なぜかCentralのメニューには仮想マシンの再起動が存在していません...）

CentralのSoft Shutdownメニューを選択し「Soft shutdown 2 slected VMs?」にダイアログにOKをクリックします。

PowerStateが、Offになったことを確認し、再度Actionボタンから「Power On」をクリックします。

起動してしばらくすると、NGTのISOが自動でアンマウントされます。

その後仮想マシンの「C:\Program Files\Nutanix\config\ngt_config.json」を確認すると、「ngt_uuid」がユニークなIDに変更されていることが分ります。

Prism Elementで該当の仮想マシンを「manage Guest Tools」確認すると、きちんとNGTが有効化されていることがわかります。

この動きはすでに、NGTがインストールされている環境には、「Nutanix Guest Agent」というサービスが起動しています。このサービスが起動時にNGTのISOがマウントされているかを確認し、マウントされている場合は、ISOから最新の設定情報を取得するという動きを行います。今回は仮想マシンの再起動で対応しましたが、「Nutanix Guest Agent」のサービスを再起動すれば同じようにngt_config.jsonが更新され自動的にNGT ISOがアンマウントされるしようとなります。

最後に、ncliでNGTの疎通ができているかを確認します。

$ ncli ngt get vm-id=4f10def8-c3c5-4757-b46e-5708f2ece29c
    VM Id                     : 00056d28-59d3-7bbc-0000-000000014005::4f10def8-c3c5-4757-b46e-5708f2ece29c
    VM Name                   : NGT-Windows Server 2019-Clone01
    NGT Enabled               : true
    Tools ISO Mounted         : false
    Vss Snapshot              : true
    File Level Restore        : false
    Communication Link Active : true ★

$ ncli ngt get vm-id=b650e0ff-1fbc-493d-aaf4-9c026a3c8baf
    VM Id                     : 00056d28-59d3-7bbc-0000-000000014005::b650e0ff-1fbc-493d-aaf4-9c026a3c8baf
    VM Name                   : NGT-Windows Server 2019-Clone02
    NGT Enabled               : true
    Tools ISO Mounted         : false
    Vss Snapshot              : true
    File Level Restore        : false
    Communication Link Active : true ★

これでクローンした仮想マシンに一括してNGTの展開と有効化ができます。

VDI環境等NGTを必要する場合に活用いただければと思います。

Nutanix Guest Toolsの構造

前回はNGTのインストール方法をご紹介しました。
今回は、NGTの構造について見ていきたいと思います。

まずはNGTの全体的な構造について見ていきましょう。

NGTをインストールしたWindowsの仮想マシンを例にして見ていきたいと思います。

NGTをインストールしたディレクトリの配下であるconfigディレクトリを見ていきます。
（C:\Program Files\Nutanix\config）

こちらに「ngt_config.json」というファイルがありますのでこちらの中を参照します。

中には以下のような情報が書き込まれています。

{"cluster_ip": "192.168.XXX.YYY", "ngt_uuid": "d4de685b-791a-4fbc-b916-6d5008bcbe2d", "ngt_version": "2.0.1", "port": 2074}

こちらのclustetr_ipには、NutanixクラスターのクラスターVIP（仮想IP）が記載されていると思います。また、ngt-uuidやport番号の記載もあります。

これを見ると分るとおり仮想マシンにインストールしたNGTは、クラスターVIPと疎通が出来ることが条件となります。

ネットワークの構成上位、特定の疎通以外は一切疎通を許されないネットワークに配置する場合（DMZなど）は、注意が必要です。

Nutanixクラスターと仮想マシンがNGT疎通できているかは、CVMから確認することが出来ます。

コマンドは、「ncli list vm-names="仮想マシン名”」となります。

今回は、「NGT-Windows Server 2019」という仮想マシン名でコマンドを実行してみたいと思います。

<ncli> ngt list vm-names="NGT-Windows Server 2019"
    VM Id                     : 00056d28-59d3-7bbc-0000-000000014005::f993eb3c-f0cb-42fe-bc13-c7d75106ed3e
    VM Name                   : NGT-Windows Server 2019
    NGT Enabled               : true
    Tools ISO Mounted         : false
    Vss Snapshot              : true
    File Level Restore        : false
    Communication Link Active : true　★

こちらを見ると「Communication Link Active」というのがあり、これがtrueであると、Nutanixクラスターと仮想マシンにインストールされてたNGTが疎通できているかが確認できます。

ポート番号からも分るように、NGTの通信は、クラスターVIPと仮想マシンが疎通は、「2074/TCP」を利用します。さらに、ゲストOSでWindowsOSを利用する場合「23578/TCP」を利用します。NGTを利用する場合、Firewall等がクラスターと仮想マシンの間にある場合は、この2つのポートを双方向であけるようにしましょう。

NGTとの疎通が行われるということは常駐するプロセスがあるということです。
Windowsの場合、NGTをインストールすると2つのサービスが登録され自動起動に設定されます。

Linuxの場合は、「ngt_guest_agent.service」と「ngt_self_service_restore.service」の2つのサービスが登録され、自動起動の設定が行われます。

NGTを利用する場合、Nutanix Guest Tools Agentは実行されている必要があります。
Self Service Restore（SSR）のサービスは利用しないのであれば停止していても問題ありません。

さて、先程の仮想マシンに展開された「ngt_config.json」の確認に戻りましょう。
もう一つ気になることがあります。それは、「ngt_uuid」というユニークなIDの存在です。これは想像できるとおり、仮想マシンUUIDとは別に、NGTをインストールした仮想マシンにはそれぞれユニークなNGTのUUIDが付与されます。

さて、ここで勘のいい人は気づいたはずです。

NGTをインストールしたマスターの仮想マシンをそのままクローンしてしまうと、後からハマってしまうことになりますので、注意が必要です。

これだと、大量の仮想マシンを展開する場合かなり大変になってしまいますので、そこは楽にNGTを展開する方法があります。方法については別の機会に紹介致します。

ではそもそもこの「ngt_config.json」は、どのように生成されるのでしょうか？

NGTのISOを確認すると、マウントしたISOに「ngt_config.json」ファイルが存在しており、既にngt_uuidも記載されていることがわかります。

この使用を考えると、仮想マシン毎にNGTのイメージがあるのか？と考えてしまうと思います。正解はYESです。

NGTのISOをPrismからマウントすると、その仮想マシンUUID毎に、設定したjsonファイルを包括したNGTのISOが作成されます。
作成されたISOは、その仮想マシンが存在するストレージコンテナの中に「.ngt」というディレクトリがあり、そのディレクトリ内に仮想マシンUUID毎にNGTのISOが保存されています。

▼ストレージコンテナの中にある「.ngt」の中

▼ディレクトリの中には、マウント時に生成されたISOが存在しています。

これから見ると分るようにNGTのISOは、仮想マシン毎に生成されますので、1台の仮想マシンでNGTのバイナリをファイルサーバー等の共有フォルダに置いて全台同じ物をインストールするとngt_uuidが同じになってしまいただしく動作しませんので1台ずつのマウントが必要となります。こちらの対策も、仮想マシンのクローンした際の対応と同じ方法で対照できますので、また改めて対策方法を説明いたします。

今回はNGTの構造について見ていきました。
NGTは、Nutanixにおける仮想マシン運用を楽にするものでありますが、NGTの構造を知っておかないと思わぬトラブルにハマることがありますので、注意が必要です。