2025年版Nutanix製品・新旧の名称紹介

Nutanixも2009年の会社創業から16年がたち、その間に新しい製品が登場したり、製品名称が変わったりしています。

Nutanixのコア製品（CVM）に関わるアーキテクチャーの根幹は、今も昔も変わりはありませんが、これからNutanixを始める人にとって昔のドキュメントを見ると今では見かけない用語に出くわすこともあるかとおもいます。（このサイトも昔の記事は昔の用語で書かれたままになっています）

本日は、今昔でNutanixの用語が変わっている部分をご紹介します。

NOS

現在は、AOSと表現しますが、その昔（だいぶ昔）は、Nutanix OSということで、NOSと言っていた時代があります。未だFoundationでバイナリ投入するディレクトリが、NOSなのはこの名残だったりします。

ABS（ Acropolis Block Service ）

現在は、Nutanix Volumes からの現在では、NUS（Nutanix Unified Storageの一部）のブロックストレージ機能として呼ばれることもあります。一方Prismの機能名称は、"Volume Group"なので、製品名や機能名称と画面が一致してないというわかりにくい部分でもあります。通称は今でもVolumesです。

AFS（ Acropolis File Services ）

Nutanix Filesからの今は、NUS（ Nutanix Unified Storage ）のファイルサーバー機能を指しています。通称は今ではFilesです。

Xtract for VMs

現在は、Nutanix Moveという名称になっています。こちらは2018年ぐらいに名称が変わっているので、Moveで慣れているユーザーは多いかと思います。逆にXtract時代を知っている人は、かなり昔からのユーザーさんであると思います。

Xi / Leap

一番最初のクラウドバックアップサービスがXi（ザイ）から始まり、Leapに名称変更となり、クラウドサービスの機能はそのままLeapでしたが、現在は新規のユーザー受け付けを終了しています。オンプレミスのLeapは、現在、Disaster Recoveryという名称になっています。Prism Centralを利用してDR環境を作成する機能です。

Xi IoT

この製品に直結する継続製品があるのかはちょっとよく分りませんが、当時は、IoT制御のプラットフォームとして提供されていました。

Nutanix Era

現在は、NDBと呼ばれているデータベースソフトウェアの管理ソフトです。個人的にはとても面白いソフトウェアだと思っているのですが、アプリケーション屋さんがNutanixの情報に触れる機会が少ないこともあり、まだまだ知名度が低い気がしています。

Nutanix Mine

Mineという製品群は、現在は販売終了しています。Nutanix Objectsをバックアップ領域として利用する形で現在は製品の体系を変えて存在しています。

Nutanix Calm

現在は、Prism Centralの機能の一部となっておりセルフサービスの機能部分を指します。オートメーション機能でブループリントからの仮想マシン展開をアシストする機能です。2016年にCalm.io社を買収し、Nutanixのオートメーション機能と統合された機能となります。

Nutanix Karbon

NKE ( Nutanix Kubernetes Engine )が純粋な後継に思いますが、Nutanix的には、現在ではNKP（ Nutanix Kubernetes Platform ）押しなので、おそらくNKPが現行の後継製品になると思います。

懐かしい製品名が沢山出てきました。KarbonやMineのように現在と製品コンセプトが異なる物は、過去のドキュメントを読むメリットはあまりないかもしれませんが、MoveやFilesなどは、昔の実装からかなり進化をしていますので、その歴史をたどるという意味では過去のドキュメントを読んでみるのも楽しいかもしれません。

 

ライブマイグレーションにおけるネットワークトラフィックの

Nutanixの設計の基礎として、AOSやAHVなど管理系で利用するトラフィックは、1つのアップリンクでまとめられており、分離されていません。vSphereであれば、vMotionや管理ネットワークをそれぞれ分離したアップリンクで構成することが多かったように思います。

Nutanixは、10Gネットワークをベースとして構成で、1Gネットワークをアップリンクの分離で分散するという複雑化する設計を排除しているところに意味があります。

そのため、Nutanixは、管理系のトラフィックとユーザーVMのトラフィックを1つのアップリンクでVLANを分けて運用という形も構成可能です。

一方で、昨今のデーター大容量化を背景に、仮想マシンに構成されるメモリーサイズが256GBやBI系ツールが稼働する仮想マシンであれば、512GBのメモリーを搭載するという構成を見かけます。

このような構成の場合、例えばLCMによるアップグレードなどメンテナンスを行う際に、仮想マシンのライブマイグレーションを行いますが、単純に512GBの仮想マシンメモリーを10Gのネットワークで転送するのは、かなり時間がかかります。
Nutanixのデフォルトのアップリンクチーミングは、Active-Backupのため、10Gアップリンクの本数を増やしたところで、実際の転送速度は変わりません。

このような問題背景から、AOS 6.7以降では、アップリンク構成にLACP（Active-Active構成）の際には、送信元を分散し帯域幅を増やしてデーターを送る機能が追加されています。

例えば、ノードあたり25Gbpsの帯域幅を持つ4ノードクラスタの場合、複数チャネルを使用した単一のライブマイグレーションでネットワーク全体を活用し、マイグレーション速度を向上させることができます。以下の表はこの構成時のトラフィック例です。

＜マルチチャネル有無でのライブマイグレーション動作の違い例＞

測定属性	複数チャネルによる ライブマイグレーション	複数チャネルを使用しない ライブマイグレーション
送信元ホストと宛先ホストでの帯域幅使用率。	50 ～ 55 % を超える帯域幅を使用し、送信元ホストと宛先ホストの両方で約 55.54 Gbps の帯域幅を提供します。	帯域幅の 10 ～ 11 % のみを使用し、送信元ホストと宛先ホストの両方で約 10.57 ～ 11.1 Gbps の帯域幅を提供します。
メンテナンスモード（EMM）タスク時間に入る	複数のチャネルを使用しない単一のライブ移行と比較すると、EMM タスク時間が約 6 分の 1 に大幅に短縮されます。

このマルチチャネルライブマイグレーションは、以下の場合に限定されます。

• マルチチャネル機能は、AHV バージョン 20220304.10055 および AOS バージョン 6.7 以上でサポートされています。
• ホストの「メンテナンスモードへの移行」および「ローカル性の復元」移行タスクでのみサポートされます。これらの移行タスクは、ホストの退避および復元操作中に並行して実行されます。

 

ユーザーオペレーションで個別にライブマイグレーションした場合は、この条件に当てはまらないので、LACPであってもシリアル転送（1ch転送）になることに注意してください。

（参考）Multichannel Support for AHV Live Migration Performance

CVMのコンソール出力情報を確認する方法

通常操作することはありませんが、たとえばハードウェアのHBAを交換したり、ストレージのエンクロージャー部分のバックプレインを交換などハードウェアのメンテナンス後、CVMが世情に起動しない場合などがあります。

原因は様々ですが（ディスクが見えてないとか、HBAの搭載場所が変わったことでPCIバスの位置が変わっているなど）、CVMがどのような状態でエラーになっているかを確認する必要があります。

しかし、CVMは仮想マシンであることとPrismのコンソール画面は、クラスターメンバーに正常に属しているホスト上で動作する仮想マシンのコンソールを確認することは出来ますが、CVMが起動していない状態では、CVMのコンソールをPrismのGUIから確認することは出来ません。

このような場合、CVMの標準出力（コンソールへの直接出力）に関しては、AHV側に保存されるように設定されています。

CVMの標準出力先：/var/log/NTNX.serial.out.0

CVMが起動途中でハングアップするなど、未知の障害に出くわした場合は、AHVのコンソールから

tail -f /var/log/NTNX.serial.out.0

コマンドでモニタリングをするほか、単純に「/var/log/NTNX.serial.out.0」ファイルをエディタ等で開きログを追いかけることで、トラブルが起きている場所を特定することが出来ます。

あまり使わない（使いたくない）機能ですが、いざというときに覚えておくと便利ですので、押えておきましょう。

 

Nutanixにおける1ノードのストレージ容量制限

昨今では、1本のHDDでも20TBを超える容量の物やNVMeも15TBを超える物など大容量化が進んでいます。

Nutanixは、HCIというメリットを生かし必要に応じてノードを追加することでストレージ容量を増やすことが出来ます。

ただ、Nutanixが稼働する1台のハードウェアでは搭載できるディスクやSSDに制限があります。この制限は、AOSのバージョンとAsync DRやDisaster Recoveryの要件により異なります。

また、AllFlashかHybrid構成かの違いでも異なります。

例えば、AOS 7.3とAllFlash構成の場合、RAW容量で1ノードあたり370TBが最大となります。
Hyvrid環境ですとこれが、212TBが最大値となります。

ストレージ1本あたりの大容量化は、HDDの方が大きいためハイブリッドの方が大きな容量が構成しやすいのですが、パフォーマンスの観点を含め、1ノードあたりハイブリッドの方が容量的に小さくなる点に注意が必要です。

一方で、Nutanixの場合大容量で利用する際に考慮していただくことは、Dedicatedモデルの存在です。NUSでファイルサーバーやObject Storageの専用利用となる場合、Dedicatedモデルを選択すると、1ノードあたりで利用できる容量が大きく変わります。

例えば、NUS 5.2の利用の場合、DedicatedでHybrid構成の場合、1ノードあたり525TBまでをRAW容量でサポートします。AllFlashモデルになると550TBまでがRAW容量でサポートされます。

ストレージ大容量化を求められる場合、ファイルサーバーや写真・動画データー、アーカイブデーターの保存などが要因で大ききなすとレージを要求されることがあります。このような場合は、用途に応じてDedicatedモデルを検討することで、コスト的もノード数も減らすことができる可能性が高くなります。

（参考）Nutanix Configuration Maximums

AOSとAHVのアップグレード順序とAOS6.5から6.10へのアップグレード時の注意

Nutanix製品は、NCI Release Modelが発表され、従来のLTS/STSに比べ製品バージョンの選定しやすくなったと思います。

アップグレードについても現在では、LCMによりコンパチビリティに適合したバージョンを自動選定してくれるので、特に考えることなく必要なタイミングに応じてアップデートをすることが可能です。

各コンポーネントのアップグレードバージョンはLCMで指定してくれますが、各コンポーネントの順序を事前に押えておく必要があります。

アップグレードの順番は、以下の順番で実行します。

1. Prism Centralのバージョンアップ（アップグレードするAOSに対応したバージョンを選択）
2. AOSをアップグレード
3. AHVをアップグレード

2と3は、LCMで同時にコンポーネントを選択することが出来ます。その場合、AOSアップグレードが優先されて行われます。

ただし、以下のバージョンにおいては、AOS 6.5から6.10にアップグレードする場合、状況によっては同一AOSバージョンないのマイナーバージョンアップや先にAHVをアップグレードする必要があります。

<対象AOS/AHV＞

AOS : 6.5 / 6.5.1 / 6.5.1.5 / 5.5.1.6

AHV : 20201105.30398 / 20201105.30411 / 20201105.30417

上記の場合は、以下のステップを踏んでアップグレードを行う必要があります。

• AOS 6.5 および AHV 20201105.30398 の場合、AOS および AHV を、AHV 20220304.x リリースをサポートする任意の AOS 6.5.x バージョン (例: AOS 6.5.6.7 および AHV 20220304.521) にアップグレードしてください。
• AOS 6.5.1、6.5.1.5、または 6.5.1.6 で AHV 20201105.30411 または 20201105.30417 の場合は、AHV を少なくとも 1 回 20220304.242 にアップグレードするか、AOS と AHV を AHV 20220304.x リリースをサポートする任意の AOS 6.5.x バージョン (例: AOS 6.5.6.7 と AHV 20220304.521) にアップグレードしてください。

このケースは大変イレギュラーのケースですが、以下のKBを参考にAOS 6.10へのアップグレードを行ってください。

KB-18147 / Upgrading AOS directly to 6.10 from early 6.5 releases with AHV 20201105.x

Prism Centralの個別ユーザーを削除する方法

Prism Centralでユーザー個別のアクセス制限が可能なRBACを紹介しました。

一時的なテストで作成したユーザーを削除しようにもPrism Centralの画面では、ユーザーを削除するメニューは表示されません。

ユーザーを削除するには、Prism Centralからnucleiコマンドで削除する必要があります。

SSH等で、Prism Centralに管理者ユーザーで接続します。

以下のコマンドを実行します。

nuclei user.list

Name              UUID                                  State
admin             00000000-0000-0000-0000-000000000000  COMPLETE
catalog-images    961fb234-1851-5e4f-aac4-bed3c178637f  COMPLETE
lcm_service       850f34bb-9942-5753-ace4-0faee81c3035  COMPLETE
nobita            585373c0-a732-5024-95fa-645bac68c846  COMPLETE
ovasystemuser123  d4e56da1-ecd1-544c-afca-64ac09498b54  COMPLETE

で、ユーザーのUUIDを取得します。

user.delete 585373c0-a732-5024-95fa-645bac68c846 confirm=true

で、ユーザーが削除できます。

（参考）Deleting a User or User Group

 

NutanixからNutanixへの移行考慮点（その4・既存クラスターと異なるメディア構成）

前回は、5年を超える古いクラスターからのNutanix to Nutanixの移行方法をご紹介しました。今回はまた別のケースの移行パターンをご紹介します。

移行課題その4 / 既存クラスターと異なるメディアのクラスターへリプレース

5年前は、SSD+HDDのハイブリッドクラスターが非常に多く採用されていました。これは、まだフラッシュメディアが高価であったことが要因であると思います。

2025年現在では、フラッシュの単価も5年前に比べ安くなったことからオールSSD構成やオールNVMeモデルの構成もあたり前に検討・導入される時代になってきました。
Nutanixにおける異なるメディアで構成されたクラスター間での移行方法についてご紹介します。

方法1.Expand Cluster + Remove Hostによるリプレース

Nutanixの最もメリットの出るリプレース方法なのですが、違うメディアで構成されたノードをExpand Clusterを行うためには、条件があります。

まず、既存の構成と新しく追加するノードの混在条件です

構成種別	既存クラスターの構成	ノード追加がサポートされる構成
ハイブリッド構成	SSD+HDD	SSD+HDD NVMe+HDD All SSD
	SSD+HDDとAll SSDの混在	All SSD
	SSD+HDDとNVMe+HDDの混在	NVMe+HDD
	NVMe+HDD	NVMe+HDD
オールフラッシュ構成	All SSD SSD+NVMeハイブリッド All NVMe	All SSD SSD+NVMeハイブリッド All NVMe

上記表に記載される構成がサポートされる構成です。例えば、既存はSSD+HDDのハイブリッド環境で、新しくリプレースするノードがAll NVMeモデルである場合、Expand Clusterによるノード追加によるリプレース作業はサポートされないということになります。

既存のSSD+HDD構成のクラスターにAll SSDノードを追加する場合、Expand Clusterによる移行方法がサポートされます。

メディアの種別が異なる場合は、上記表を元にノード追加がサポートされる構成かを事前に確認しておく必要があります。

（参考）Mixing Nutanix Nodes in a Cluster

▼条件を満たしていれば、Expand Cluster + Remove Hostをサポート

方法2.Async DRの利用

Async DRであれば、メディアの制限を受けることはありません。そのため、SSD+HDDの環境から、All NVMeのクラスターにレプリケーションし仮想マシンを移行する方法が利用可能です。

▼メディアに関係なくAsync DRは移行可能

方法3.Nutanix Moveを利用した仮想マシン移行

Nutanix Moveは、ハイパーバイザーの種別にもハードウェアのメディア構成にも影響を受けません。そのためMoveでの移行は、サポートされます。（MoveがサポートしているAOSバージョンであれば、バージョンに関係なく利用可能です）

方法4.Cross Cluster Live Migration

AOSやAHVのバージョンが同一であることが条件ですが、この条件に適合している場合は、Cross Cluster Live Migrationによる無停止移行が可能です。

既存クラスターと異なる環境の場合、Expand Clusterによる1クラスターに統合した移行を行う場合、1クラスターに混在できるハードウェアの種別に制限があります。1クラスターでメディア混在ノードの継続運用ではなく、一時的な移行であってもメディア混在のノードを拡張する場合は、注意を行ってください。

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からNutanixへの移行考慮点（その1・Nutanix+ESXiからNutanix+AHVへの移行）

2015年から本格的にNutanixが日本市場に浸透し、Nutanixを新規で導入するユーザーが爆発的に増えている最近ですが、一方でNutanixからNutanixへの移行というフェーズも多く見かけるようになりました。10年前と違いNutanixで選択できる幅が大きく増えていることから、改めてNutanixからNutanixへの移行について見ていきたいと思います。

移行課題その1
ESXiからAHVへのハイパーバイザー変更

方法1.Convert Clusterによる変換後のExpand Cluster+Remove Host

2020年前後までは、Nutanix+vSphere ESXi環境で稼働している環境も多かったのではないでしょうか？VMwareの買収もあり、vSphereからNutanix AHVへの移行を検討されている場合増えています。この場合、Nutanixの既存のクラスターに追加ノードでAHVのノードを追加し移行するという構成が組めません。

この場合2つの方法があります。

1つは、既存のNutanixクラスターをConvert ClusterでESXi上で稼働しているクラスターをAHVにハイパーバイザーを変更します。（仮想マシンは、NGTがインストールされていることが前提となりますが、そのままAHVで稼働する仮想マシンに変換されます）

コンバート完了後、AHVクラスターになった状態で新規ノードを追加し、リプレース対象のノードをRemoveすることで、リプレースを完了することができます。

この場合、ESXiからAHVにコンバートする際に、ハイパーバイザーの入れ替えやCVMの作り替えが行われるため、Foundationを行うのと変わらないぐらいの時間（3ノードであればおよそ1時間程度）かかります。さらに内部でVMDKをRAW形式に変換する動作を行いますので、それなりにクラスターの停止時間がかかってしまいます。

▼既存クラスターのハイパーバイザー変換

コンバートが変更した後、追加ノードを入れて1つのクラスターにします。

▼Expand ClusterでAHVクラスターとして6ノード構成にする

その後、古いノードをRemove Hostで外すことで、新しいノードのみで継続稼動させることができます。

▼Remove Hostで古いノードの切り離しを行う

方法2.Async DRの利用

こちらが移行としては、時間がかからない方法の1つであると思います。クラスター間のレプリケーションであるAsync DRを設定し仮想マシンの移行ができます。こちらを利用すれば、Prismの操作画面のみで簡単に仮想マシン単位で移行計画を作ることができます。

NGTがインストールされていない場合、Async DRのMigrate機能ボタンがPrism上では押せませんが、ncliで「skip-vm-mobility-check」パラメータを利用すれば、NGTのインストール有無に関係なく仮想マシンの移行ができます。（NGTをインストールしていない場合、ゲストOSにVirtIO Driverがインストールされていないため仮想マシンのOSが正しく起動できない可能性があります。その場合事前にVirtIO Driverのインストールを行ってください。）

方法3.Nutanix Moveを利用した仮想マシン移行

Nutanix to Nutanix移行であってもハイパーバイザーが異なる場合、Nutanix Moveを利用して移行することができます。

移行元のNutanixクラスターと移行先のNutanixクラスターを設定することで、Nutanix Moveのメリットを生かした仮想マシン単位かつ移行時間をカットオーバー機能で自由に制御できます。

▼Moveを使った仮想マシンの移行

今回は、Nutanix+ESXi環境からの移行についてご紹介しました。ハイパーバイザーが異なるからNutanixでも移行は無理みたいな印象がある方に出会うことがありますがそのようなことはなく、Nutanixの良さを生かした移行が可能です。

次はまた違う移行パターンについてご紹介します。

 

Prism Elementのキーボードショートカット

Prism ElementやPrism Centralには、素早く操作ができるキーボードショートカット機能があるのをご存じでしょうか？あまり目立たない機能ではありますが、さっと処理したいときには意外と便利かもしれません。

本日は、キーボードショートカットについてご紹介します。

Prism Element/Prism Centralにおけるキーボードショートカット

キー	メニューオプション
m	メインメニュー (Elementのみ)
s	歯車メニュー
f or /	Spotlight (検索)
u	ユーザーメニュー
a	アラートメニュー (Elementのみ)
h	ヘルプメニュー
p	最近のタスク

これらのキー操作でメニューを表示させることができます。

ダッシュボードには以下のキーショットカットがあります。

キー	メニューオプション/表示
o	概要ビュー
d	ダイアグラムビュー
t	テーブルビュー

▼ダッシュボードの以下の部分をキーボードで切替えできます。

あまり目立つ機能ではありませんが、知っていて損はしない機能かと思います。（過去のプロフェッショナル試験でショートカットキーの問題が出たこともありますので、試験対策としても覚えておきましょう）

 

Prismのオペレーションログ

Nutanix環境を複数人やチームで管理する場合、どのようなオペレーションで何が行われたかを監査を含め記録する必要があるかもしれません。

Nutanixの場合、Prism Elementにおいては、オペレーションの履歴記録を行うことが出来ません。タスクのログは確認できますが、操作したユーザーが記録されませんので、履歴としては不十分な所があると思います。

操作履歴に関しては、Prism Central側に記録されます。Prism Elementで操作した内容もPrism Centralに記録されます。より厳格な権限を持って管理をする場合は、Prism CentralのRBAC機能と併用することで操作できる機能やオブジェクトを制限しつつ操作ユーザーと操作内容を記録できるため、管理としては良い形になると考えられます。

操作ログは、Prism Centralの「Infrastructure」メニュー → 「Activity」 → 「Audits」から、確認することができます。

Prism Centralでのログ保持期間が保存期間として適合できない場合は、ログをSYSLOGサーバーに転送することも可能です。

 

LCMのトラブル対処方法 2025年追加情報

Nutanixに搭載されているLCMは統合的なアップデートをコンパチビリティやアップグレードパスに合せて適切なバージョンアップバイナリを提示・アップグレードを行う便利なツールです。一方で様々場ハードウェアプラットフォームやNutanixの多くのソフトウェアをLCMで統合的に管理をしていることから、思わぬトラブルに出会うこともあります。

トラブル内容は様々あるのですが、最近のLCMバージョンで見受けられる2つの障害に対する対処法をお知らせします。

その1）LCMのインベントリがハングアップし、再度インベントリを実行することができない

まず、CVMにSSHでログインします。

lcm_leader

で、リーダーを探し、そのリーダーのCVMにSSHで接続します。

genesis restart

で、Genesisを再起動します。

（参考）KB18089:LCM 3.x: Inventory task in hung state

その2）Prism Central 7.3にアップグレード後LCMの画面がエラーで表示されない

ブラウザのバージョンが古いとただしく表示されません。
Google Chrome、Microsoft Edgeの場合「バージョン110」以上が必要となります。

（参考）KB19624:LCM Page Fails to Load with 'toSorted is not a function' Unexpected Error After PC 7.3 Upgrade

あわせて「Nutanix LCMのおさえておきたいポイント」もご確認いただくと、LCMの急なトラブルにであっても慌てず対処可能だと思います。

 

AHV上の仮想マシンでHyper-Vを稼動させる（Nestedの方法）

AHV環境においてPrismから仮想マシンを作成したデフォルト状態の場合、Hyper-Vをインストールしようとすると、以下のようなエラーメッセージが表示され、Hyper-V機能をインストールすることはできません。

AHVには、 「hardware_virtualization」という機能設定を有効化することでHyper-Vをインストールすることができます。AOS7.3で確認する限り、「cpu_passthrough」パラメーターであっても、Hyper-Vをインストールすることができます。

元々、Nestedの場合、「cpu_passthrough」が使用されておりましたが、このパラメーターではHyper-Vは動作しませんでした。（ESXiのNestedは、cpu_passthroughパラメーターで動作します）
Nutanixが、WSL2の対応を行う際に「hardware_virtualization」パラメーターが新たに追加されました。WSL2が、内部的にHyper-Vエンジンを内部で利用しているため、「hardware_virtualization」パラメーターを有効化することで、Hyper-Vの動作に対応したというのがその背景にあります。

では、この「hardware_virtualization」を有効化する方法をご紹介します。

まず、CVMにSSH等でシェルにログインします。

以下のコマンドを実行します。

acli vm.update <仮想マシン名> hardware_virtualization=true

※該当の仮想マシンは、パワーオフの状態で実行してください。

コマンド実行完了後、通常通り仮想マシンを起動し、Hyper-Vを有効化します。

これで、Hyper-Vを動作させることができます。

vSphere ESXiの場合は、仮想マシンが仮想スイッチを通じて外部ネットワークと疎通する場合、仮想スイッチの無差別モード（プロミスキャスモード）の設定変更が必要であったりしますが、AHV環境の場合は、仮想スイッチの設定変更などは特に必要ありません。

AOS 7.0以降は、Nestedの仮想マシンのライブマイグレーションにも対応したことから、利便性が増したと言えるかと思います。

AHV上の仮想マシンにさらにハイパーバイザーをインストールし仮想マシンなどを動作させるNestedに関しては、サポートに制限があります。
Nested環境でサポートされるのは、以下の2つの機能のみとなります。

• Credential Guard
• WSL2（Linux 用 Windows サブシステム 2）

上記機能以外は、サポートされていないことから、Hyper-VをAHV上の仮想マシンで動作させることは、サポート対象外となりますので、検証目的など一時的な環境として利用される場合にご利用ください。

（参考）ネスト化された仮想化は AHV でサポートされていますか？

（参考）Windows Subsystem for Linux (WSL2) Support on AHV

 

管理ユーザーのパスワード変更方法とadminユーザーのパスワード有効期限設定

標的型攻撃やランサムウェアによる被害が増えている昨今、これらの被害を防止するための予防策を講じておく必要があります。

Nutanixにおいては、様々悪意のある攻撃を防御する機能がありますが、セキュリティの基本である管理者アカウントのパスワードをデフォルトから変こしておく必要があります。

Prism Central 7.3からは、Prism Centralのアカウントはもちろん、所属しているクラスターのCVMやAHVの管理者ユーザーのパスワードを変更することができます。

「Infrastructure」メニュー → 「Network & Security」 → 「System Accounts」

から、変更が可能です。

なお、Prism Centralでのパスワード変更の場合、ハードウェアのIPMIで利用するアカウントのパスワードは変更できません。

IPMIのパスワード変更、またはPrism Centralを展開する前にパスワードの変更を先に行いたいというケースもあるかともいます。その場合は、コマンドで対応を行います。

IPMIのパスワード変更

IPMIのGUI画面から変更も可能ですが、AHVから以下のコマンドで変更可能です。

ipmitool user set password user_id new_password  

※各ホストごとに行う必要があります。

AHVのパスワード変更

SSHなどでAHVのシェルにログインします。

passwd root

※各ホストごとに行う必要があります。

CVMのパスワード変更

password nutanix

※任意のCVMで実行すれば全てのCVMで同期されます

なお、AHVやCVMのパスワード変更はAOS 7.x系からPrism Centralでの変更が推奨されています。

なお、Prismのadminユーザーは、60日が有効期限となりパスワードの変更が必要となります。パスワードポリシーによっては、ゆこう期限を短くしたい場合や長くしたい場合などそれぞれ事情があるかと思います。
adminユーザーのパスワード有効期限を変更するには、CVMにSSH等でログインし以下のコマンドを実行します。

パスワードを変更できない期間を指定

sudo chage -m MIN-DAYS admin

パスワードの有効期限を設定

sudo chage -M MAX-DAYS admin

例えば外部システム連携などの影響で、パスワードを変更を要求設定を長くするためには、以下のコマンドを実行します。（あまり推奨はされませんが..）

sudo chage -M 9999 admin

管理者のアカウントのパスワードは、厳密に管理とアクセス制限を行う必要があります。

Nutanixを初めて導入したら、忘れずにデフォルトパスワードを変更してください。

Nutanixでは、管理者カウントをデフォルトパスワードを利用している場合、NCCによりチェック・警告されます。

（参考）Controller VM Access

（参考）KB6153:NCC Health Check: default_password_check, pc_default_password_check and file_server_default_password_check

nutanixやadminユーザーがロックされた場合の対応

CVMやAHVにSSHでログインして作業することは、メンテナンス時にまれに行うことがあるかともいます。普段行わない作業のため、nutanixユーザーのパスワードやAHVのrootパスワードを忘れてしまい、アカウントロックされてしまう問題に遭遇する可能性があります。そのような際の対処法をご紹介します。

まずは、CVMにログインを行います。

CVMにログインするnutanixユーザーのパスワードを忘れたんだよ！という方は、慌てずPrismでログインするadminユーザーのパスワードでCVMにSSH等でログインします。

CVMになにかしログインができればOKです。
状況によって、以下のコマンドを実行します。

AHVのrootユーザーのアカウントロックを解除する場合

hostssh "faillock --user root --reset"

CVM上のnutanixユーザーのアカウントロックを解除する場合

allssh "faillock --user nutanix --reset"

CVM上のadminユーザーのアカウントロックを解除する場合

allssh "faillock --user admin --reset"

AOS 6.7以降でAOS6.10.1.9、AOS7.0.1未満の場合、ロックされたユーザーは自動でロック解除されません。AOS6.10.1.91/AOS 7.0.1以降、AHVは、20230302.102001以降は、ロックされたユーザーは、900秒後にロック解除されます。

（参考）
KB17355:Users nutanix/admin and root are not getting unlocked automatically after 900 seconds