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の構造を知っておかないと思わぬトラブルにハマることがありますので、注意が必要です。