LCMのDirectUploadを使ったダークサイトでの運用（その1）

以前より、Nutanixのコンポーネントアップデートは、従来のOneClick Upgradeから、LCMに置き換わってきていることをお伝えしてきました。

一方LCMは、インターネットにNutanixクラスターが接続されている場合は、さほど難しくないものの、インターネットに接続が出来ないいわゆるダークサイトの場合、Webサーバーをローカル環境に立てて、Webサーバーを経由してアップグレードするコンテンツを配布する必要がある旨をご紹介してきました。

このダークサイトの運用ですが、LCM Version 2.4.1.1から、ダイレクトアップロードという機能が搭載されています。

アップグレードができるコンポーネントは、LCMのバージョンによって異なります。

Ver	サポートコンポーネント
2.4.1.1	AHV,Foundation,Foundation Platforms,NCC
2.4.2	AOS,Diles,File Analytics
2.4.3	HPE DX ファームウェア
2.4.3.1	Cluster Maintenance Utilities (CMU)
2.4.4	DELL XC/XC Coreファームウェア
2.4.5	Nutanix NXファームウェア Fujitsu XCファームウェア Insupur ファームウェア
2.5	NVidia GRIDドライバー

現在は、LCM2.5がリリースされており、GPUドライバーのアップデートまでサポートできるようになりました。

ここまで来れば、ではLCM2.4.1.1以降を利用すればWebサーバーを利用すること無く、ぁプレートが出来るから楽だなと感じてしまいます。

しかし、新規構築環境の場合、気をつけることがあります。それは、初期イメージング時のAOSによって、初期展開されるLCMのバージョンが異なることです。

確認する限り、AOS 5.20.4.6では、「2.1.6835」が搭載されています。AOS 6.5.0でも、LCM 2.3系が標準搭載されています。（AOS 6.5.1は、「LCM 2.4.3.1」が同梱されています。）

そのため、AOS 5.20.4.6やAOS 6.5.0の場合、LCMをダークサイトで利用するためには、まずLCM自身ののアップデートのために、Webサーバーが必要になるという前段階の作業が発生してしまいます。

DirectUploadをするために、わざわざWebサーバーを用意しないといけないのであれば、そもそも全部Webサーバー経由でアップロードするという判断になりかねませんが（それはそれで構いません）、いずれにしてもモヤモヤしながらもWebサーバーを用意する必要があります。

今回は、ダークサイトでWebサーバー経由でLCMをアップデート後、DirectUploadで、各コンポーネントをアップグレードする手順をご紹介します。

まず、Webサーバーは、Apacheやnginxなどでも構いませんが、今回は、Windows Server 2022のIISを利用した方法をご紹介します。IISの場合、いくつかの手順が追加で必要になりますので、あわせてご紹介をいたします。

まずは、サーバーマネージャーから「役割と機能の追加」からIISをインストールします。

IISを選択します。

役割とサービスはデフォルトのままでウィザードをすすめます。

IISのインストールが終わったら、まず必要なコンポーネントをNutanix Support Portalからダウンロードしておきます。

まずは、LCM Framework Bundleをダウンロードします。

取得した、ファイルは、Cドライブの配下にLCMというフォルダを作成し、さらにその配下に「release」というフォルダを作成し、「release」フォルダの配下に、先ほどダウンロードした、LCMバイナリを展開します。

続いて、IISの管理画面を開きます。

「Default Web Site」を右クリックし、「仮想ディレクトリの追加」をクリックします。

エイリアスに「lcm」、物理パスは、先ほどLCMのバイナリを配置した「C:\LCM」（releaseではなく、その上位のLCMフォルダ）を選択します。

続いて、ディレクトリのファイル一覧表示を有効化します。

ディレクトリの参照機能を有効化します。

続いて、MIME形式を追加します。IISは、自分に登録されていないMIME形式のファイルを外部からリクエストされた場合は、リクエストを拒否するためそのための対策となります。

右側の「追加」ボタンをクリックし、以下のMIME形式を登録します。

拡張子	形式
.sign	text/plain
.json	text/plain　（既に登録済みだと思います）
.iso	text/plain
.xz	text/plain

続いて、LCM側の設定変更を行います。PrismのLCM画面から、「Inventory」を選択し、Settingsをクリックします。

Local Web Server (Darksite)を選択し、URLに「http://IISを立てたWebサーバーのIPアドレス/lcm/release」を指定し、Saveボタンをクリックします。

この「release」というディレクトリ名が重要です。Nutanix LCMでは、releaseフォルダの配下にバイナリを配置する決まりがあります。

ここまで準備が出来たら、「Perform Inventory」を実行します。（Auto Inventoryで定期実行するか聞かれますが、Webサーバー側の場合、手動でバイナリを入れ替えない限りアップデートされませんので、有効化する必要は説くにありません）

アップデートが実行されますので、しばらく待ちます。（ノード数によりますが、最低でも30分ぐらい見て置いた方がいいと思います）

しばらくすると、LCMの画面が最新化されるはずです。（最新化されなくてもLCMが完了後再度LCMを開き直すと画面メニューが横になっているのがわかるはずです）

これでLCMのバージョンが最新版にアップグレードされ、Direct Upload機能に対応するLCMにすることが出来ました。

次回は、LCMのDirect Uploadの利用方法についてご紹介いたします。

仮想TPM機能を生かしてWindows 11を稼動させる ～AOS6.5の機能紹介（その5）～

Windows 11がリリースされて約1年。AHVにおいては、今までTPMの仮想化機能が提供されていなかったので、正式な方法でWindows 11のインストールが出来ませんでした。

Windows 11をインストールするためには、以下の環境が必要となります。

1. 1GHz以上で2コア以上のx64プロセッサー
2. 4GB以上のメモリー
3. 64GB以上の記憶装置
4. UEFI セキュアブート
5. TPM 2.0を搭載
6. DirectX 12をサポート(WDDM 2.0ドライバー)するグラフィックカード

（参考）Windows 11 の仕様、機能、コンピューターの要件を確認する

ここで仮想化環境でハードルになってくる部分は、UEFI セキュアブートとTPM2.0の部分になります。UEFI セキュアブートについては既にAOS 5.20系でサポートされていますので、問題ありませんが、TPM2.0の要件をAHVは、満たしていませんでした。

しかし、先日リリースされたAOS "6.5.1"とAHV "Nutanix 20220304.242"のバージョン組み合わせで、仮想TPMに対応しました。（AOS 6.5.1は、LTSリリースになりますので、長期サポートを受けることができます）

従来AOSの新バージョンと併せてAHVもセットでリリースされることが多かったのですが、今回は、AOSのリリース日とは別に2022/9/29に、"20220304.242"としてAHVのバージョンが大きく上がる形で単独リリースされました。またWindows 11に対応した"VirtIO Driver 1.2.1"を利用します。
（AOS 6.5.1にバンドルされたAHVは、"AHV-20201105.30411"になります。AHV-20201105.30411では、仮想TPMに対応していませんので、AHVを個別でアップグレードする必要があります）

なお、TPM利用においては、今後のバージョンでPrism上で操作できるようになる予定ですが、リリースしたてのAOS6.5.1との組み合わせの場合、acliコマンドで仮想TPMを有効化する必要があります。

まずはじめに、普通通りに仮想マシンをPrism上で作成します。

仮想マシンを作成する際には、UEFIを選択してください。併せて、Diskの項目で予め作成されているIDEのCDROMドライブを削除し、CDROMドライブは、SATAを、DISKは、原則SCSI（なんらかの事情が場合はSATA）を選択してください。

VirtIO DriverとWindows OSの2つのISOを利用しますので、CDROMドライブは、2つ用意しておくと便利です。

続いて、SSHを利用して、任意のCVMに接続します。

接続後、以下のコマンドを実行します。

acli vm.update "仮想マシン名" virtual_tpm=true

コマンド実行後「complete」と表示されれば設定完了です。

SSHを閉じた上で、作成した仮想マシンをパワーオンします。

Windows 11のインストーラーが起動したら順次ウィザードを進めていきます。

ドライバー一覧が表示されますので、全てのドライバーを選択します。
全てのドライバーを選択することで、NICなどディスク以外のデバイスもOSインストール時にドライバーが適用されます。

あとはウィザードをすすめ、インストールを行います。
Windows 11の環境条件が整っていない仮想マシンの場合、インストール自体がそのままの状態では出来ませんので、インストールまでウィザードが進むと言うことは、仮想マシンが、Windows 11の要件を満たした環境であることが分ります。

インストールのウィザードをすすめていくと、無事にWindows 11のインストールが完了すると思います。

デバイスマネージャーでも、TPM2.0が認識されていることがわかります。

Prismの操作だけでは無く、acliでコマンド実行をするという一手間は入ってしまいますが、レジストリなどを操作すること無く、通常の操作だけでWindows 11がインストールできるようになりました。

Windows 11で、VDI環境を作る場合などは、AOS 6.5.1とAHV-20201105.30411以降のバージョンを利用して構築しましょう。

仮想マシンテンプレートを更新する ～AOS6.5の機能紹介（その4）～

前回は、仮想マシンテンプレートを利用した、テンプレートの登録と展開という基本的な動作を確認しました。

実際の運用では、テンプレートで作成した仮想マシンも時間が立てば古くなるため、インストールしたソフトウェアのアップデートやOSのセキュリティパッチ適用が必要になると思います。

今回は、テンプレートのアップデート機能をご紹介いたします。

テンプレート画面から、更新したいテンプレートを選択し、「Update Guest OS」をクリックします。

どのバージョンを更新するかを選択します。初回テンプレート登録時は初期しかありませんので、「Initial Version」を選択し、「Proceed」をクリックます。

次に流れが表示されます。仮想マシンがデプロイされるのでその仮想マシンで、アップデート処理を行って頂き、アップデート後そのイメージを反映させます。

更新用仮想マシンが展開されます。展開が完了すると、メンテナンス用の仮想マシン名称が表示されます。このリンクをクリックすると、PrismCentralの仮想マシン管理画面にジャンプしますのでそのまま仮想マシンのメンテナスが可能です。

該当の仮想マシンをパワーオンしアップデートの作業を行います。
作業が完了したら、仮想マシンを終了します。

アップデート完了後、Prism Centralの画面から「Complete Guest OS Update」をクリックします。

続いて、新しいバージョンの名称や更新した内容を入力します。テンプレートをそのまますぐに反映させる場合は、「Yes, set this new version as active」をチェックを入れます。（今回は、このタイミングでは未チェックで更新します）
最後に、Complete Updateをクリックします。

次に、実際に利用するテンプレートのバージョンを切り替えます。
テンプレートをクリックし名をクリックし、バージョンを表示させます。

デフォルト展開のテンプレートを指定することができます。Configmをクリックすることで指定したテンプレートバージョンがActive化されデフォルトのテンプレートとして利用されます。

なお、古いバージョンのテンプレートも先ほどのバージョン一覧画面からチェックを入れれば展開が可能です。また利用しなくなったバージョンは削除することも可能です。
（Activeに設定されたバージョンは削除できません）

テンプレート機能でバージョン管理ができる点は、非常に便利だと思います。
また、内部的にはNutanixのストレージスナップショット機能を利用した差分データーブロック管理を行っているため、ストレージ容量が削減できる点も評価のポイントであると思います。

仮想マシンをテンプレート化する ～AOS6.5の機能紹介（その3）～

従来から、仮想マシンをテンプレート化する機能はありますか？とAHV環境のNutanixにおいてよく聞かれることがあります。

ImageServiceはありましたが、この機能がvSphereのテンプレート機能の補完になるとは正直言い難いところもあり、かつテンプレート機能はなくても、マスターVMをクローンすれば使えるという側面もあり、機能実装もなかなか優先度が上がっていなかったように感じますが、ついにPrismCentralにおいて仮想マシンのテンプレート機能が実装されました。

こちらもAOS6.5での実装という扱いになっていますが、実際には少し前のPrism Centralから利用可能となっております。

本日はこのテンプレート機能についてご紹介いたします。

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

• AHVクラスターのみが対象となります。（vSphere/Hyper-V仮想マシンは、Prism Centralからテンプレート管理できません）
• テンプレートは、ソース VM から、「ホスト アフィニティ属性」「HA 優先度属性」「Nutanix ゲスト ツール (NGT) 」の属性をコピーしません。
• RF1 コンテナー上にあるディスクを持つ VM から VM テンプレートを作成することはできません。

一方で普通のテンプレート機能にはめずらしい、テンプレートのバージョン管理機能を持っています。

まずは、新規でテンプレートを追加してみましょう。

まずは、PrismCentralからテンプレートにしたい仮想マシンを選択し、右クリックから「Create VM Template」をクリックします。

テンプレート化するにあったての設定が行えます。そのまま展開もできますが、Sysprepやcloudiitを使ったカスタマイズが可能です。（今回はカスタマイズなしとしてみます）
なぜか、Localeが、英語とフランス語しかないのはよくわかりません...。日本の場合は、Englishを選択すればよいかと思います。

「Allow users to override at VM Deployment?」は、一部のパラメーターをユーザーがテンプレートから展開する際に変更可能を許可するかの有効/無効パラメーターとなります。（今回は有効にしてみます）

次に進むとサマリーが表示されますので、確認して保存をクリックします。

手順はこれだけです。これでテンプレートは完了です。何も難しいことはありません。

このテンプレートはどこで管理されるのでしょうか？テンプレートのソースVMのRecoverPointを確認すると、テンプレート用の仮想マシンとしてスナップショットを取得していることがわかります。すなわち、テンプレートのイメージはソースクラスターのストレージ内で保存されていることがわかります。テンプレートはクラスターをまたいで展開ができるため、ソースVMが存在しない別クラスターで展開する場合は、イメージの転送が行われるため、その時間は考慮しておく必要があります。また、PrismCentralから該当のクラスターを登録から外すと不具合が発生すると思われますので、この点も注意が必要です。（あとからNutaixクラスターをPrism Centralから登録解除することは、まずないと思いますが）

では、テンプレートからのDeployも確認してみましょう。

テンプレート画面から、展開したテンプレートをチェックし、「Deploy」ボタンをクリックします。

展開ウィザードが開始されます。今回はAdvancedをクリックして詳細画面を見ていきましょう。

ここで、仮想マシンの展開する情報を入力します。仮想マシン名称から展開する台数や、仮想マシンのスペックも指定が可能です。
なお、展開するクラスターは、マスターVMが存在していたクラスター以外に、Prism Centralで管理しているクラスター内で展開可能です。

必要な情報を入力後、「次へ」をクリックします。

続いて、NICのネットワーク割り当てなどを確認します。BIOS/UEFIは、モード変更は、この画面ではできません。（おそらくできても意味がないと思います）

設定内容を確認後、次へをクリックします。

続いて、サマリーページが表示されますので、サマリーページを確認後Deployをクリックします。なお、サマリーページから再度設定パラメーターを変更することもできます。

これで、仮想マシンは展開されます。カスタマイズを設定していた場合、パワーオン時にカスタマイズスクリプトが実行される形となります。

動きを見れば大した話ではないのですが、これでテンプレートの管理及び展開は完了です。

ここまでは基本編でしたが、次回は、テンプレートの更新管理についてご紹介します。

イメージサービスへの仮想ディスク登録～AOS6.5の機能紹介（その2）～

従来からAHV上で、仮想マシンにマウントするISOイメージやテンプレート的に利用する仮想ディスクファイルを登録する、イメージサービス（現状のPrismの日本語だとイメージ設定と表記されています）

イメージサービスにISOやqcow2の仮想ディスクイメージを登録する場合は、PrismからHTTP経由でPUTするか、NFS経由でのPUTに対応しています。一方で既にNutanixのストレージコンテナ上に存在している仮想ディスクについては、acliコマンドを利用しないと登録が出来ませんでした。

このコマンドは従来紹介をしましたが、現在ではディスクのUUIDがわからなくても、仮想マシン名とディスク接続バスと接続ID（接続順）を指定することで登録が出来るようになっています。

image.create イメージ名称 image_type=kDiskImage  clone_from_vmdisk=vm:仮想マシン名:バスID(例scsi.0)

従来は、clone_from_vmdiskというパラメーターが無かったのですが、現在では子のパラメーターを利用することで、仮想ディスクのUUIDを探す必要が無くなりました。

しかし、とはいえコマンドでの作業というのはちょっと面倒なときもあります。

Prism Centralを利用すると現在では、仮想マシンの仮想ディスクをImageServiceに登録できるようになりました。

Prism Centralの「Compute & Storage」の「Images」を選択します。

Add Imagesから、イメージ登録画面に進み、「VM Disk」を選択します。

すると、仮想マシンの検索画面が表示されますので、ImageServiceに登録したい仮想マシンを選択し、仮想ディスクを選択し、右の「＋」をクリックします。

続いて、イメージ名称を入力し、Nextをクリックします。

続いて、イメージの場所配置を決定します。

画面が壊れていますが、上側は、イメージ元が存在しているクラスターのみに登録をする場合、下側は、カテゴリーに属するクラスター全てにイメージをコピーする場合に利用します。

カテゴリーとImageServiceの管理については後日改めて詳細をお伝えしたいと思います。

このウィーザー度が終了すれば、イメージが登録されます。

マウス操作だけで出来るようになった点は1つの進歩であると思います。

AHVホストのメンテナンスモードについて～AOS6.5の機能紹介（その1）～

NutanixでAHVの環境でもメンテナンスモード機能が存在しています。

このメンテナンスモードですが、従来acliコマンドでしか設定が出来ず、かつメンテナンスモードになっているかどうかを直接的にPrism画面から確認することが出来ず、acliでメンテナンスモードにしたまま気づかないということもあります。メンテナンスモードにしてもCVMは起動したままで、ストレージサービスは継続されます。あくまでもADSの機能などで仮想マシンがメンテナンスするホスト上で稼動できないようにする機能となります。そのため、余計に気づきにくいという側面があります...。

メンテナンスモードは、PrismのHardwareメニューの画面から行う事が出来ます。

Enter Maintenance Modeをクリックすると以下のようなメッセージが表示されメンテナンスモードに移行が可能です。

メンテナンスモードに移行中のホストは、ホスト部分でくるくるアイコンが表示されます。

当然ながら、メンテナンスモードに移行するホスト上で稼動していた仮想マシンは、ライブマイグレーションされます。RF1で構成された仮想マシンやアフィニティールールで他のホストに移行できない仮想マシンはシャットダウンされます。

その後、CVMが自動でシャットダウンされます。（この動作は、acliのメンテナンスモード時の処理と異なっています）

意図的にCVMだけを起動して状態を確認すると、Cluster Statusで確認すると、メンテナンスモードに設定したホストのCVMは、CVM自体もメンテナンスモードになっていることがわかります。

acliのメンテナンスモードでは、ホストのメンテナンスモードにしかなりませんが、Prismからのメンテナンスモードの場合は、ホストのメンテナンスモード、CVMのメンテナンスモード、そしてCVMがシャットダウンされる処理が一括して行われます。（ホストはシャットダウンされません）

CVMがシャットダウンされると、「Exit Maintenance Mode」ボタンがクリックできるようになります。

Exit Manurenance Modeをクリックすると、CVMが起動し、自動的にメンテナンスモードが解除されます。

メンテナンスモードを終了すると、CVMとホストのメンテナンスモードが終了され、自動的に仮想マシンが再配置されます。

なお、Redandancy Factorの構成に従って、N+2の場合であれば、1ノードを超えるホストのメンテナンスモードは行う事が出来ないようになっています。

では、acliでホストだけをメンテナンスモードにした場合は、Prism上ではどのように表示されるのかを見てみましょう。

まずは、acliでホストのメンテナンスモードを実行します。

acli host.enter_maintenance_mode 192.168.38.161 mode=live
EnterMaintenanceMode: complete

この場合、CVMは起動したかつ、CVMは、メンテナンスモードでは無く通常稼動していますが、Prism上ではメンテナンスモードになっていることがわかります。また、メンテナンスモードの終了もPrismから出来るようになっています。

ただ、ドキュメント上では、「You must exit the node from maintenance mode using the same method that you have used to put the node into maintenance mode. For example, if you used CLI to put the node into maintenance mode, you must use CLI to exit the node from maintenance mode. Similarly, if you used web console to put the node into maintenance mode, you must use the web console to exit the node from maintenance mode.」という記載があるので、これは機能上出来るけれども、正式なオペレーションとしては、メンテナンスモードに移行したオペレーションでメンテナンスモードを終了することが推奨されるようです。
実際に、この状態でExit Manitenance Modeをクリックするとなぜか、CVMがシャットダウンされた上で、エラーになってしまいました。このドキュメント通りこのオペレーションはサポートされていないようです。

（参考）Node Maintenance (AHV)