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

 

Prism Centralの活用その7（ストレージコンテナのマイグレーション）

vSphere環境においては、Datastoreに配置した仮想マシンを別のDatastoreに配置変更する、Storage vMotionが存在します。

Nutanix+AHV環境においては、従来の3Tierストレージのように利用用途に応じてDatastoreを分ける運用は非効率なため、ストレージコンテナを複数作るケースは、そこまで多くなかったことから、実装としてもそこまで重要視されていないように思われました。

しかし、ストレージのポリシー違い（圧縮・重複排除やデータ冗長度）で複数ストレージコンテナを作成するケースはあり、運用ポリシーの変更で、仮想マシン（仮想ディスク）を別のストレージコンテナに移行したいケースは0ではありません。

そのため、仮想ディスクのストレージコンテナの移行については、AOS 5.19のアップデートで実装されたことを以前に紹介しました。

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

この当時、acliコマンドでしか操作ができなかったのですが、現在では、Prism Centralを介すことで、既に作成された仮想マシンの仮想ディスクを別のストレージコンテナに移行することができます。

では、そのオペレーションをご紹介します。

まずは、Prism Centralの「Infrastructure」から「VMs」を開きます。

仮想ディスクのストレージコンテナを変更したい仮想マシンを選択し、「Update」をクリックします。

仮想マシンのvCPU等の変更画面が出ますので、特に変更の必要が無ければそのまま「Next」をクリックします。

続いて、Disksの画面を確認します。

ここでは、1つの仮想ディスクが「000.DEFAULT-MSG-CONTAINER」に配置されております。この仮想ディスクを鉛筆マークをクリックし変更を行います。

ここから、移行したいストレージコンテナを選択します。

選択後Updateをクリックします。

ただ、Update VMの表示は変更されません...。（多分バグだと思います）

選択後、あとはNextを数度クリックし、サマリーを確認します。

個々の表示も、移行前の仮想ディスクの表示になります。（おそらく現在の配置されているストレージコンテナが表示される仕様なのでしょう...）気にせずSaveをクリックします。

すると、Updateが行われ、タスクには、Migrate vDiskのタスクが作成され、仮想ディスクの移行が行われます。

タスクが成功すると、仮想マシンのUpdateから情報を見るとストレージコンテナが今回変更した「WORKING-CONTAINER」に変更されていることがわかります。

未だに、コマンド含めVolume Groupのストレージコンテナ移行は、サポートされていませんが、GUIで操作ができるようになったことで、少しオペレーションのハードルは下がったかと思います。（UI表示が所々おかしいですが）

Prism Centralの活用その6（テンプレートから展開時にSysprepを自動実行する/その4）

前回までに、Sysprepで一般化した状態でシャットダウンした仮想マシンをテンプレート登録しました。併せて、テンプレート登録時に「unattend.xml」の内容を登録し、Sysprepにおける応答ファイルを自動で適用されるように設定しました。

この設定が反映されたうえで展開されるかを含め、実際にテンプレートから仮想マシンを展開してみたいと思います。

では早速仮想マシンを展開してみましょう。

Prism CentralのVMsから「Create VM from Templaet」を選択し、先ほど登録した、「Windows 11 Enterprise 24H2」を選択し、「Begin」をクリックします。

ここでは、仮想マシン名と展開台数を入力します。ここでは、展開台数を5台にしてみましょう。Startup Scriptを見ると、テンプレート登録時に登録したXMLの情報が記載されています。個別で別のXMLの内容をこちらで入力することもできます。

Advanced Deployでスペック等も変更可能ですが、今回はこのまま、「Next」をクリックします。

サマリーが表示されます。ポイントは、CDROMドライブの存在です。この環境では、テンプレート展開時に2台のCDROMドライブで構成された仮想マシンを登録していますので、テンプレート時の構成である2台のCDROMドライブを搭載した状態で展開されます。

そのまま「Deploy」をクリックします。

Deployボタンを押すと、ストレージブロックのポインターベースのクローンのため、瞬時に仮想マシンが展開されます。

では、展開した仮想マシンを一斉に起動してみましょう。

Lunch Cosoleで見ていると仮想マシンが起動しSysprepが動作しているのがわかります。ここまでくると後はしばらく待つばかりです。

一度再起動がかかり、以下のような画面が出ますが、まだ我慢です。

再び再起動します。もうちょっとの辛抱です。

すると、自動でデスクトップが表示されました。

コンピューター名も変更され、ADに参加していることがわかります。

Active Directoryのサーバーから見ても、コンピューターアカウントが5台登録されていることが確認できます。

SysprepによるAD参加までの設定が完了したことがわかりました。

さて、これでよかったよかったと思いたいところなのですが、あのSysprepのXML定義は一体どうやって仮想マシンに渡されたのでしょうか？今回は、AD参加のため、ネットワークに接続することが前提でしたが、ネットワークに接続できない環境であってもSysprepの定義ファイルを指定可能です。

この謎は、まずテンプレートから展開された仮想マシンの構成を見てみましょう。

Update VMから仮想マシンの構成を見ると、テンプレート登録時には、CDROMドライブは2台でしたか、いつしか3台に変わっており、かつ一番下のドライブを見ると、何らかのISOがマウントされていることがわかります。

展開されたOSから見ると、この環境の場合Fドライブとして3台目のドライブが認識しており、「cidata」というボリューム名が見えます。

中を見ると、Prism Centralでテンプレート作成時に見たXMLの内容がファイルになっています。

つまり、Sysprepのファイルは、CDROMドライブを経由し、ファイルを渡していることがわかります。

では、このISOはどこに存在しているのでしょうか？

Prism Elementで、確認すると「SelfServiceContainer」に存在しているISOをマウントしていることがわかります。

このUUDIのISOを探してみましょう。

SelfServiceContainerの中身を、WinSCPで覗いてみると

「SelfServiceContainer\.vm_customization_isos」配下に、作成されていることがわかります。

他にもたくさんのISOがあるので、これは仮想マシンごとに作成され、おそらくずっとそのまま放置され続けるのではないかと思います...。

また、もっと重要なことは、テンプレートからSysprepをかけて展開した仮想マシンは、必ずこのISOをアンマウントしてください！このISOは、自動でアンマウントされません！

XMLの定義ファイル内に、ローカルアカウントのパスワードや、Active Directoryに参加する用のメンテナンス用アカウントのユーザー名やパスワードが記載されている場合、そのまま利用者に渡すとアカウント情報の漏洩につながる可能性があります。

通常、Sysprepする場合は、マシン自体にカスタマイズ用の「unattend.xml」を配置し、Sysprep実行後バッチ等で削除する運用が一般的かと思います。
Nutanixのテンプレート機能の場合は、仮想マシン自体にファイルで配置するのではなく、ISOマウントになりますので、手動でアンマウントするか、何らかの形で自動でアンマウントする方法を考える必要があります。

このSysprep自動実行機能は、大変便利な機能ではありますが、最後に重要な落ちがありますので、注意が必要です。

かならず展開後はISOアンマウントだけはお忘れなく。

 

Prism Centralの活用その6（Sysprepが利用可能なテンプレートを作成する/その3）

WindowsやLinuxが入った仮想マシンを一括で展開したい場合、併せてホスト名やIPアドレスなどのカスタマイズも自動で行いたいものです。

Windowsの場合は、特にActive Directoryに参加する際、複数の仮想マシンが同じホスト名で参加すると動作に不具合が生じますし、SIDが重複しているとWSUSなど一部の機能が正常に動作しない場合があります。

Windowsの場合は、Sysprep、Linuxの場合は、cloud-initを利用して、仮想マシン展開時に独自のパラメーターにカスタマイズすることができます。Nutanixは、もちろん仮想マシンクローン時にSysprepやcloud-initと連携して、カスタマイズが可能です。

今回は、よく利用されるWindowsとSysprepの連携方法をテンプレートを使ってご紹介いたします。

まずは、テンプレートになる仮想マシンを用意しましょう。

今回は、Windows 11 Enterprise 24H2を用意しました。VDIの場合、VDIソフトウェアを利用した一括展開ができるので、あまりNutanixの機能を利用してクローンは行わないかもしれませんが、手動でのVDI環境構築や、もちろんサーバーOSでも同じ手順でSysprepを実行した仮想マシンを展開可能です。

Windows 11は、UEFIブート、セキュアブート、vTPM有効化などWindows 11の条件に従って仮想マシンを作成し、OSのインストールを行ってください。

OSのインストールを行ったら、Windows Updateや、あらかじめ利用するソフトウェアのインストールなど必要な作業を行ってください。

さて、準備ができたら、以下の作業を行います。

• セットアップ時に作成したローカルアカウントを削除し、ローカルのAdministratorユーザーを有効化し、Administratorユーザーでサインインする
• シャットダウン制御を行うため、「AHV環境におけるWindows仮想マシンのシャットダウンについて」を参考に画面の省電力OFFと、ロック時のシャットダウンを有効化する（任意）
• デフォルトで有効化されるビットロッカーを無効化する
  「manage-bde -off c: 」を実行し、「manage-bde -status」で、暗号化領域が0%になっていることを確認する
• Sysprep中にストアアプリのエラーが出る場合は、ストアアプリを削除する（後述）

Sysprepを実行する前に、インストール漏れなどがないように、一度OSをシャットダウン後にスナップショットを取得しておくことをお勧めします。

では、実際にSysprepを実行します。

ファイル名を指定して実行から「c:\windows\system32\sysprep\sysprep」を実行します。

Sysprepで、SIDを再生成する必要がありますので、「一般化する」にチェックを入れ、シャットダウンを選択してください。（再起動を選択すると、再起動をSID再生成処理が走ってしまいますので、テンプレート化してもSIDが再生成されません）

では、OKを押してSysprepを実行します。

が、おそらく以下のような「SysprepでWindowsのインストールを検証できませんでした。詳細については～」メッセージが出るのではないかと思います。

何らかの理由でSysprepが失敗していると考えられます。

まずは、指定された「C:\Windows\System32\Sysprep\Panther\setuperr.log」を参照します。

このログを見ると、LanguageExpreriencePackja-JPのパッケージが原因でSysprepに失敗していることがわかります。ほかにもEdgeなどで同様に引っかかる場合もあります。

この場合、PowerShellで該当のストアアプリパッケージを削除する必要があります。

上記のログの場合、以下のコマンドをPowerShellで管理者権限で実行します。

Get-AppxPackage -AllUsers <パッケージ名> | Remove-AppxPackage -AllUsers

上記ログの例）

Get-AppxPackage -AllUsers Microsoft.LanguageExperiencePackja-JP | Remove-AppxPackage -AllUsers

実際にPowerShellでの実行の画面

この状態で再度、Sysprepを実行し、一般化にチェックを入れて「シャットダウン」を選択し、OKをクリックします。

再び同じエラーが出ることがあります。

場合は、再度C:\Windows\System32\Sysprep\Panther\setuperr.log」を参照します。

ここでは、新たなログとして、WidgetsPlatformRuntimeが引っかかっているのがわかります。

同様に管理者権限で、パッケージを削除します。

Get-AppxPackage -AllUsers Microsoft.WidgetsPlatformRuntime | Remove-AppxPackage -AllUsers

再び、Sysprepで「一般化する」にチェックを入れ、「シャットダウン」を選択し、OKをクリックします。

今度は、画面が変わりました。このプログレスバーが表示されるダイアログが表示されたらあとは、少し時間がかかりますが、その後自動でOSがシャットダウンされます。

では、次に作成した、Windows 11のマスターをテンプレートに登録します。

Prism CentralのVMsから、テンプレートにしたい該当のマシンをチェックし、「Action」から、「Create VM template」を選択します。

次にテンプレートの名称及び、メモを入れます。
今回、SysprepのXMLは、あらかじめ登録しておくようにします。

Script Typeを「Sysprep(Windows)」を選択し、ConfigurationMethodを「Custom Script」を選択します。

次に、本来Sysprep時に、「unattend.xml」ファイルとして記載するXMLの内容を「Startup Script」　の中に記載します。

今回サンプルで以下のような条件でファイルを記載しています。

• ホスト名をランダムに変更
• ADに参加（参加用のユーザー・パスワードを記載）
• 言語を日本語に設定
• 初回アニメーションを無効化するレジストリを追記
• 初回起動時に「C:\script\startup.bat」を実行
• 初回起動時にドメインユーザーでログイン（ユーザー・パスワードを記載）
• EULAや無線LAN設定などをスキップする
• オンラインアカウント登録を無効にする

設定した内容は、以下の通りです。

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
  <settings pass="specialize">
    <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64"
               publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
               xmlns:wcm="http://schemas.microsoft.com/WMIConfig/v2002/State"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <ComputerName>*</ComputerName>
      <TimeZone>Tokyo Standard Time</TimeZone>
    </component>
    <component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="amd64"
               publicKeyToken="31bf3856ad364e35" language="neutral"
               versionScope="nonSxS"
               xmlns:wcm="http://schemas.microsoft.com/WMIConfig/v2002/State"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <Identification>
        <JoinDomain>toriten.oita</JoinDomain>
        <Credentials>
          <Domain>toriten.oita</Domain>
          <Password>toritenpassword</Password>
          <Username>ikoi</Username>
        </Credentials>
      </Identification>
    </component>
  </settings>
  <settings pass="oobeSystem">
    <component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/v2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <InputLocale>ja-JP</InputLocale>
      <SystemLocale>ja-JP</SystemLocale>
      <UILanguage>ja-JP</UILanguage>
      <UserLocale>ja-JP</UserLocale>
    </component>
    <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/v2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <OOBE>
        <HideEULAPage>true</HideEULAPage>
        <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
        <HideLocalAccountScreen>true</HideLocalAccountScreen>
        <ProtectYourPC>3</ProtectYourPC>
        <HideOnlineAccountScreens>true</HideOnlineAccountScreens>
      </OOBE>
      <DisableAutoDaylightTimeSet>false</DisableAutoDaylightTimeSet>
      <FirstLogonCommands>
        <SynchronousCommand wcm:action="add">
          <CommandLine>reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v EnableFirstLogonAnimation /t REG_DWORD /d 0 /f</CommandLine>
          <Description>Disable First Logon Animation</Description>
          <Order>1</Order>
        </SynchronousCommand>
        <SynchronousCommand wcm:action="add">
          <CommandLine>c:\script\startup.bat</CommandLine>
          <Description>Run FirstRun Batch Script</Description>
          <Order>2</Order>
        </SynchronousCommand>
      </FirstLogonCommands>
      <UserAccounts>
        <LocalAccounts>
          <LocalAccount wcm:action="add">
            <Password>
              <Value>local-password</Value>
              <PlainText>true</PlainText>
            </Password>
            <Name>nakayoshi</Name>
            <Group>Administrators</Group>
          </LocalAccount>
        </LocalAccounts>
      </UserAccounts>
      <AutoLogon>
        <Password>
          <Value>toritenpassword</Value>
          <PlainText>true</PlainText>
        </Password>
        <Username>maruyama</Username>
        <Enabled>true</Enabled>
        <Domain>toriten.oita</Domain>
      </AutoLogon>
    </component>
  </settings>
</unattend>

実際にXMLの内容を入力したうえで、「Next」をクリックします。

最後にサマリーの画面が表示されますので、ここで確認を行います。

注意してほしいことは、今回の事例では、ADに参加する処理が入っていますので、テンプレートから展開された仮想マシンがDHCPでIPアドレスを取得できる環境を用意しておく必要があります。IPAM設定、またはDHCPサーバを仮想マシンのVLANに用意しておく必要があります。（ADに参加しない場合など、Sysprep時にネットワークに接続する要件がない場合は、Sysprep時のネットワーク接続は必須ではありません）

これで、テンプレートの作成は、完了です。

長くなってしまったので、次回で実際の展開の動きを確認したいと思います。