NutaNice Xperience

主にNutanix製品を検証したり触ったりした結果をつづっています。※このブログの内容は個人の見識や見解をもとに作成しています。参考にされる場合は自己責任でご活用ください。実際に製品を使用される場合は、メーカードキュメントの手順に従い実施してください。

Nutanix AHVの仮想マシンテンプレートを使ってみる② ~カスタマイズなし編~

※このブログの内容は個人の見識や見解をもとに作成しています。参考にされる場合は自己責任でご活用ください。また、このブログで紹介している製品や機能を使用される場合は、メーカードキュメントの手順に従い実施することを推奨します。

AHV VMテンプレートの連載リンク集

前回の記事では、Nutanix AHVでの仮想マシンテンプレート機能について紹介しました。今回から数回にわたって、AHV環境でのテンプレート機能の使い方をお見せします。

1. 今回の環境

Hardware Platform: NX-1175S-G8
AOS: 6.5.3.7 LTS
Hypervisor: AHV 20220304.423
Prism Central: pc.2023.3
テンプレート対象VM: Windows Server 2022

※作業イメージは以下の通りです

今回は簡易版として、SysprepなどのカスタマイズなしでVMテンプレートを作成し、作成後にテンプレートからVMをデプロイしてみます。

2. テンプレート化するVMの準備

▽テンプレート化するVMですが、今回はWindows Server 2022をインストールした仮想マシンを準備しました。こちらをまずシャットダウンしておきます。

簡単ですが準備はこれで完了です。

3. VMテンプレートの作成

▽Prism Central Webコンソールを起動しログインします。

▽Prism Centralの「Infrastructure」画面にて、対象の仮想マシンを選択し「Create VM Template」をクリックします。

▽テンプレート名を入力したら、Guest Customizationにて今回は「No Customization」を選択し「Save」まで進めます。

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

4. テンプレートからのVMデプロイ

▽Prism Centralの「Infrastructure」画面にて、作成したVMテンプレートを選択し「Deploy VMs」をクリックします。

▽以下画像の通り入力してデプロイします。今回は3台同時にデプロイしてみました。

▽テンプレートからデプロイされたVMをパワーオンしてログインしてみます。

▽ログインできました。

 

5. カスタマイズなしテンプレートのホスト名やSIDについて

一般的に、Sysprepなどを実行せずにVMをクローンしたりテンプレートからデプロイしたりすると、ホスト名やユーザーSIDなどが重複しますが、AHVの場合も同様です。

▽今回は、カスタマイズなしでテンプレート作成→VMデプロイを実施しましたが、同時デプロイしたVMの中身を比べると以下の通りとなります。

このように識別子が重複していると、AD参加をする際などに不具合が生じたりします。そのために、Sysprepによるシステムのクリーンアップなどが一般的に使用されますが、次回はAHV VMテンプレート環境におけるSysprepの使用方法を紹介したいと思います。

6. Advanced Deployについて

テンプレートからVMをデプロイする際に「Advanced Deploy」というメニュー選択できます。これを使用すると、VMに割り当てるリソースを変更したり、ネットワークを変更したり、カスタムスクリプトを後で追加したりすることが可能です。

▽「Advanced Deploy」の中身をお見せしますので、ざっと眺めてみてください。

おわりに

今回はカスタマイズなしでVMのテンプレートを使用してみました。次回はAHV VMテンプレートにおけるSysprepの使い方について紹介します。

参考リンク
VM Template Management(AHV Administration Guide)
https://portal.nutanix.com/page/documents/details?targetId=AHV-Admin-Guide-v6_7:mul-vm-template-create-manage-pc-c.html
VM Template Management(Prism Central Infrastructure Guide)
https://portal.nutanix.com/page/documents/details?targetId=Prism-Central-Guide-vpc_2023_3:mul-vm-template-create-manage-pc-c.html

次回
Nutanix AHVの仮想マシンテンプレートを使ってみる③ ~Sysprep応答ファイル編~

Nutanix AHVの仮想マシンテンプレートを使ってみる① ~紹介編~

※このブログの内容は個人の見識や見解をもとに作成しています。参考にされる場合は自己責任でご活用ください。また、このブログで紹介している製品や機能を使用される場合は、メーカードキュメントの手順に従い実施することを推奨します。

AHV VMテンプレートの連載リンク集

この記事では、Nutanix AHVで利用できるVMテンプレート機能について紹介します。仮想化製品では「仮想マシン テンプレート」という機能が一般的に提供されていますが、Nutanix AHVでも仮想マシンのテンプレート化・デプロイの機能が提供されています。

仮想マシンテンプレートについて

テンプレート機能の主な特長は、ゲストOSや必要なアプリを事前にインストールした状態でVMをテンプレート化したり、Sysprepの応答ファイルなどによる自動セットアップをテンプレートからのデプロイ時に利用したりできる点です。

検証用で同じ構成のVMを何度もデプロイするような環境や、複数のVMを自動でAD参加までセットアップしたい場合などにおいて、単純作業の繰り返しを自動化できる便利な機能です。

Nutanix AHVにおけるVMテンプレートは、Prism Centralからのみの操作となりますが、NCI Starterライセンスがあれば追加のライセンスなどは不要です。

AHV でのVMのテンプレートの制限事項

テンプレート機能の主な制限事項は以下の通りです。

  • AHV上のVMのみ対象
  • エージェントVMやPrism Centralは不可
  • ボリュームグループが接続されているVMは不可
  • RF1ストレージコンテナ環境のVMは不可
  • プロテクションドメインで保護されているVMは不可

その他の制限事項については以下リンク先をご参照ください。

おわりに

今回は、AHVでの仮想マシンテンプレートについて紹介しました。次回以降、テンプレート機能の使い方について紹介したいと思います。

Nutanixにおける「STIG」や「SCMA」の紹介 ~後編~

※このブログの内容は個人の見識や見解をもとに作成しています。参考にされる場合は自己責任でご活用ください。また、このブログで紹介している製品や機能を使用される場合は、メーカードキュメントの手順に従い実施することを推奨します。

前回の記事では、NutanixにおけるSTIGの実装やレポート発行、セキュリティダッシュボードなどを紹介しました。今回はセキュリティチェック&自動修復機能としてNutanixに標準搭載されている「SCMA」について紹介します。

1. SCMAとは

SCMA(自動セキュリティ設定管理 - Security Configuration Management Automation)は、クラスター内のCVMやAHVといったコンポーネントがSTIGなどのセキュリティベースラインを遵守しているかを定期的にモニタリングしており、ベースラインから逸脱している場合は自動修復してくれる機能です。

この機能はNutanixに標準搭載されており、内部で勝手に稼働しているものですので、普段は特に意識する必要はありません。

<参考>
SCMA Implementation
https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Security-Guide-v6_5:sec-security-scma-implementation-wc-c.html

2. SCMAポリシーの設定状況の見かた

SCMAの設定状況はnCLIやセキュリティダッシュボードにて確認できます。nCLIでは、例えば以下コマンドを実行すると、CVMのセキュリティ設定に関わる内容が確認できます。

[nutanix@cvm]$ ncli cluster get-cvm-security-config

実行結果は以下の通りです。例えばSCMAの実行スケジュールがHOURLYになっていることなどが確認できます。

[nutanix@cvm]$ ncli cluster get-cvm-security-config

Enable Aide :                      false
Enable Core :                      true
Enable High Strength P... :  false
Enable Banner :                  false
Enable SNMPv3 Only :       false
Schedule :                          HOURLY
Enable Kernel Core :           true
SSH Security Level :           DEFAULT
Enable Lock Status :           false
IP Restriction State :          NORMAL
SSH whitelisted addres... :

[nutanix@cvm]$

また、AOS 6.6以降およびPrism Central pc.2022.9以降で使用できるセキュリティダッシュボードの「Security Hardening」ウィジェットでも、SCMA実行のスケジュールが確認できます。

この項目をクリックすると、AHVとCVM個別にSCMA実行のスケジュール設定を変更することができます。

3. 実際に修復してくれるか確認

CVMやAHVの設定がセキュリティベースラインを逸脱すると、SCMAは本当に元のベースラインに設定を戻してくれるのかを確認してみます。

今回は、パスワードの最低文字数の設定をわざとベースラインから外れるように変更してみます。RHELのSTIGガイドラインでは15文字以上のパスワード設定が必要ですが、Nutanixでのデフォルトは最低8文字以上となります。

現在の最低文字数の設定は以下のコマンドで確認できます。

[nutanix@cvm]$ grep minlen /etc/security/pwquality.conf

実行結果は以下の通りです。今回はデフォルト値の8となります。

[nutanix@cvm]$ grep minlen /etc/security/pwquality.conf
minlen = 8

[nutanix@cvm]$

このように、パスワードのセキュリティレベルの設定は「/etc/security/pwquality.conf」に記述されていますので、これをviエディタなどで直接編集します。今回はデフォルト値の「8」⇒「6」に変更してみます。

[nutanix@cvm]$ sudo vi /etc/security/pwquality.conf

#Configuration for systemwide password quality limits
#Defaults:
#
====中略======
#Minimum acceptable size for the new password (plus one if
#credits are not disabled which is the default). (See pam_cracklib manual.)
#Cannot be set to lower value than 6.
minlen = 6
#

====中略======
[nutanix@cvm]$

これで、ユーザパスワードの最低文字数は6文字に設定されました。あとは、次のSCMAチェックまでしばらく放置するだけです。

この記事ではあまりリアル感は伝わらないかもしれませんが、しばらく置いてから再度設定ファイルを確認してみると、以下のようにデフォルト値の「8」に戻されていました。

[nutanix@cvm]$ grep minlen /etc/security/pwquality.conf
minlen = 8

[nutanix@cvm]$

おわりに

いかがでしたでしょうか?「SCMA」はSTIGなどにもとづいたNutanixのセキュリティベースラインを自動チェックしてくれる機能であり、ベースラインからの逸脱があると自動で設定を修復してくれるため、一定のセキュリティレベルを維持し続けてくれることがお分かりいただけたかと思います。

次回はAHVやCVMのセキュリティ強化機能などについて書いてみたいと思います。

Nutanixにおける「STIG」や「SCMA」の紹介 ~前編~

※このブログの内容は個人の見識や見解をもとに作成しています。参考にされる場合は自己責任でご活用ください。また、このブログで紹介している製品や機能を使用される場合は、メーカードキュメントの手順に従い実施することを推奨します。

Nutanixにおける「STIG」や、それに準拠するためにNutanixがCVMに搭載している「SCMA」について紹介します。Nutanixのセキュリティ実装についての理解にぜひご活用ください。前編では、STIGについて解説します。

1. STIGとは

STIG(Security Technical Implementation Guide - セキュリティ技術導入ガイド)とは、アメリカ国防総省のセキュリティ機関である国防情報システム局(DISA - Defense Information Systems Agency)が公開しているセキュリティ強化のためのガイドラインです。WindowsLinuxといったOSに限らず、VMwareやNutanixなど様々なベンダー製品に対して、セキュリティベースラインとその設定手順が提供されています。各ベンダーはこのベースラインに準拠しつつ、独自のカスタマイズを加えて製品のセキュリティレベルを最適化しています。

STIGのガイドラインはDISAのサイトで一般公開されており、誰でも見ることができます。
https://public.cyber.mil/stigs/

▽リンク先のドキュメントライブラリで例えば「nutanix」と検索すると、Nutanix AOSでのSTIG実装ガイドやその手順がダウンロードできます。

▽また「Red Hat」で検索すると、RHEL用のSTIGも公開されています。

▽これらをダウンロードしたものの中に、XML文書(+XSL)がありますので適切なブラウザ設定で展開すると以下のようなガイドが確認できます。これがSTIGの生のガイドラインです。

▽スクロールして中身を確認すると、例えば以下のような項目と手順が確認できます。

このような細かい設定内容がこのドキュメントでは100項目以上公開されています。

▽また、NutanixのコアコンポーネントであるCVMやAHVはCentOSであるため(AOS 6.5時点)、RHELのSTIGが導入されています。RHELのSTIGについては例えば以下のような内容が公開されています。

NutanixはSTIGの導入について以下のページで紹介しており、RHELのSTIGにおける独自の実装についても言及していますので、併せてご確認ください。
DISA STIG Guidance Reference
https://portal.nutanix.com/page/documents/details?targetId=Nutanix-compliance-for-RHEL-STIGs-v6_5:Nutanix-compliance-for-RHEL-STIGs-v6_5

2. STIGレポートの発行

AOS 6.6以降では、CVMからのコマンド操作でSTIGのレポートを作成することができます。手順に従ってレポートを発行すると以下のようなテキストファイルやHTMLベースのレポートが作成され、STIGの遵守状況を確認することが可能です。

テキストファイル

HTMLファイル

コマンドラインでのSTIGレポート発行方法については以下をご参照ください。

Generating STIG Compliance Report
https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Security-Guide-v6_7:sec-stig-report-create-pe-ncli-t.html

3. Prism Centralの「セキュリティダッシュボード」でSTIGポリシーの確認

AOS 6.6以降およびPrism Central pc.2022.9以降が導入されている場合は、Prism Central Webコンソールにて「セキュリティダッシュボード」が利用可能です。

▽セキュリティダッシュボードのSTIGポリシーウィジェットにて、STIGの準拠状況が確認できます。以下画面の例では、RHELのSTIGガイドラインのうち18項目が設定されていない(Failed)ことを示しています。

▽さらに中身を見てみると、RHEL STIGのどの項目がFailedとなっているのか確認できます。

Nutanixのデフォルト設定では、RHEL STIGのすべての項目に準拠するようにガチガチの設定でクラスターが構成されるわけではありませんが、利用者にて後で設定変更する際には、何が設定されていないのかが視覚的に見やすいので便利です。

Security Dashboard
https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Security-Guide:mul-security-dashboard-overview-pc.html

おわりに

いかがでしたでしょうか?前編では、NutanixにおけるSTIGの実装について紹介しました。みなさまのNutanix製品理解の一助となれば幸いです。後半では、SCMAについて解説します。

次回: Nutanixにおける「STIG」や「SCMA」の紹介 ~後編~

Nutanix File Analytics の監査データ保持期間(v3.3.0時点)

Nutanix Filesのデータ分析や監査データの確認ツールとして使用可能な「File Analytics」の監査データ保持期間は最大1年間です。(v3.3.0時点)

1年間を超えるデータは、欲しいデータをCSVで定期的にエクスポートして保存するといった事を検討する必要があります。

以上。

 

Nutanix Moveで仮想マシンをAHVからAWS EC2へ移行してみる

今回はNutanix AHV上の仮想マシンAWS EC2へ移行してみます。

目次

今回の環境

4ノードのNutanix AHVクラスター
プラットフォーム: NX-1465-G5
AOS: 6.5.3.5 LTS
Move: 4.9.1
移行対象VM: Windows Server 2019

今回の作業イメージは以下の通りです。

1. 移行対象のVMに対する事前準備

仮想マシンAWSへ移行するためにはいくつかの要件や事前準備項目があります。ドキュメントから抜粋したものを以下に示しました。(Move 4.9.1時点)

  • サポートされるOS
  • WinRM, RDP, SSH を有効化(Windowsの場合)
  • Nutanix Guest Tools(NGT)をインストール

※要件や制限事項の詳細は以下リンク先をご確認ください。
▽Migration Considerations
https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Move-v4_9:top-migration-considerations-ahv-aws-c.html

2. AWS側の準備

AWS EC側では、リージョンやアベイラビリティゾーン、移行先のネットワーク(VPC)などを事前に準備しておく必要があります。また、Moveへの環境登録時にはAWSアカウントの「アクセスキー ID」と「シークレットアクセスキー」が必要となります。

MoveからAWSに対して操作を実行しますので、登録時に使用するAWSアカウントには、IAMにて特定の権限(許可)を持たせておく必要があります。

多くの場合、管理者権限を持つアカウントであれば対応できるかと思いますが、Moveのドキュメントでは許可ポリシーで必要な権限のリストがJSONで公開されていますので、必要に応じてAWSユーザーに権限を持たせておきます。

▽許可ポリシー作成の画面

Nutanixで公開されているJSONは以下をご参照ください。
▽Requirements (AHV to AWS)
https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Move-v4_9:top-requirements-ahv-aws-r.html

3. Move VMのデプロイ

Nutanix Moveは仮想アプライアンスとして提供されており、移行元のAHVクラスター上に仮想マシンとしてデプロイして使用します。

Moveのデプロイ方法については以下記事をご参照ください。
Nutanix MoveをAHVへデプロイしてみる(Prism GUI編) - NutaNice Xperience

4. Moveへの環境登録

デプロイしたMoveのWebコンソール画面から移行元AHVと移行先AWSを登録します。

AHV環境の登録方法は以下記事をご参照ください。
MoveでのAHV環境の登録

AWS環境の登録方法は以下記事をご参照ください。
MoveでAWS環境の登録

5. 移行プランの作成

環境の登録ができたら移行プランを作成します。
▽Moveコンソールにて「Create a Migraton Plan」をクリックします。

▽移行プランに名前を付けて「Proceed」をクリックします。

▽以下のように設定していきます。

▽続いて移行対象の仮想マシンを選択します。今回は「MovetoAWS」という名前のWindows Server2019仮想マシンを選択しました。ちなみに、NGTが対象のVMにインストールされていない場合、この時点で仮想マシンを選択できない仕様となります。

▽次の画面で移行元AHVネットワークと移行先AWSネットワーク設定をします。移行先のAWSでは、ネットワークとサブネット、セキュリティグループを選択します。

▽続いて準備モードで今回は「Automatic」を選択します。

Windowsの管理者権限のあるアカウントのID/PWを入力します。※複数の仮想マシンでID/PWが異なる場合は「Change settings」から個別に入力することも可能です。

▽今回はプライオリティを「Medium」に設定します。AWS移行後にパブリックIPアドレスを持たせたい場合は「Create Public IP Address」にチェックを入れます。ちなみに「Schedule Data Seeding」では、移行対象の仮想マシンスナップショットのレプリケーションを開始する日時を指定することができます。

▽サマリ画面で設定内容を確認したら「Save and Start」でプランを実行します。すぐに実行したくない場合は「Save」でプランの保存のみも可能です。

6. Seeding(レプリケーション)の実行

▽プランが検証されて、実行に移ると「In Progress」と表示されますので、「In Progress」をクリックしてタスクの実行状況を追跡します。

▽Moveコンソールでは、対象VMのスナップショットが取得され、AWSレプリケーションされている様子が確認できます。また、AWS EC2のEBSにてレプリケーションされたスナップショットも確認できます。「移行」を実行するまで、最新のスナップショットがデフォルト10分間隔でレプリケーションされ続ける仕組みとなります。

7. Cutover(移行)の実行

移行先に仮想マシンを切り替えたいというタイミングで「Cutover」というボタンをクリックします。「Cutover」を実行すると、移行元の仮想マシンが停止して最後のスナップショットがレプリケーションされたのち、移行先のAWS EC2でインスタンスが作成されます。

リモートデスクトップで接続したところ、移行したWindowsにログインできました。

ちなみに、移行元の仮想マシンは停止しているだけですので、何かの事情で移行元の仮想マシンが必要となった場合はそのまま電源を入れて使用できます。

その他ナレッジ

AWS認証エラーについて

AWS環境の登録時や、移行プランの作成・検証でMoveがAWSにアクセスしているタイミングで以下のようなエラー画面が何度も出てきました。

AWS GetRegionNames failed with error: AuthFailure:~~~~~~~~~

AWSへのアクセス認証に失敗しており、提供されたアクセス情報を検証できないというエラーです。私の場合は、何度も再実行すると、認証が通ったりしましたので、何らかの原因で不安定な状態になっていたのかもしれません。

もし許可ポリシーなども正しく設定しているのに、認証エラーになるといった、同様の事象に遭遇している方がいれば参考にしてみてください。

サポート外のOSについて

Move 4.9.1時点で、ドキュメント上Windows Server 2022はサポート対象外ですが、実際に移行できるのかやってみたところ、移行プラン作成後にサポート対象外としてエラーとなりました。(※自動準備モードでエラーとなるなら、手動モードでスクリプトを準備すればいけるのかもですが...。)

Windows Server 2022はMoveの現行バージョンでは移行できませんので、将来バージョンのリリースを待つか、別の方法を考える必要があります。

移行後のAWSインスタンスタイプについて

移行元AHVでの仮想マシンのvCPUやメモリサイズに応じて、移行先AWSではどのインスタンスタイプが選択されるのかを3パターンに分けて検証したところ以下のようになりました。

移行後のOS側からも、インスタンスタイプ通りのリソースが確認できます。

上記の事から、移行元のvCPU、メモリサイズをカバーするようにAWS EC2側でインスタンスタイプが自動選択されていることが分かります。(移行元よりもリソースが少ないという状態にはならない。)

終わりに

今回はNutanix AHV上の仮想マシンAWS EC2上へ移行する方法を紹介しました。このようにMoveではパブリッククラウドにも仮想マシンを移行することができますので、皆様の今後のハイブリッド・マルチクラウド戦略にぜひご活用いただければと思います。

<参考>
Move User Guide Ver 4.9.1 > AHV to AWS
https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Move-v4_9:top-ahv-to-aws-vm-migration-c.html