NutanixのSSP（Self Service Portal）再入門（その3）

![image.png](https://qiita-image-store.s3.amazonaws.com/0/84474/d441f906-e9bc-116d-ba5f-ae7020c38577.png)
本記事は、Nutanix Advent Calendar 2018、とは関係ありませんが、Nutanix Advent Calendar 2018の2枚目の4日目、24日目投稿分の続きとしての投稿になります。
https://adventar.org/calendars/3174

本記事の内容は、この日付時点の情報（AOS 5.10/Prism Central 5.10）に基づいています。そのため，今後新しいバージョンが提供された場合に，当該記載と矛盾が生じる場合がありますのでご注意ください。

NutanixのSSP（Self Service Portal）再入門（その1）
https://qiita.com/hanakara_milk/items/4491c26a58402135868f

NutanixのSSP（Self Service Portal）再入門（その2）
https://qiita.com/hanakara_milk/items/294dd756b4bc9fd170a5

#はじめに
この記事ではNutanixをシステム管理者以外のユーザーとして利用する際に利用可能なセルフサービスの機能であるSSPについて、NutanixのSSP（Self Service Portal）再入門（その1）及び（その2）で改めて紹介してきましたが、その続きとなります。

その1ではSSPの成り立ちや概要までを紹介し、前回、その2では実際にSSPをどのように利用していくのか、ユーザーがSSPを利用するにあたってシステム管理者が何をしなければいけないのか、SSPユーザーでVMの作成、削除、更新、参照（利用）の操作にとって非常に重要な役割を担うカタログについて紹介をしてきました。

その3では、いよいよSSPにユーザーログインしてVMの作成や操作をどのように行っていくか、について紹介していきます、

#SSPユーザーによるSSPの利用
ここからSSPユーザーによるSSP（Prism Central）へのアクセスを行い、システム管理者でログインした際との違いやVMの作成、削除、更新、参照（利用）の方法、操作について見ていきます。

##SSPユーザーでのSSP（Prism Central）へのログイン
これまで何度も「SSPユーザーでのSSP（Prism Central）へのログイン」や「アクセス」と言う言葉を用いてるのは、SSP（Self Service Portal）にアクセスすると言っても、実態としてはPrism Centralにシステム管理者のクレデンシャルではなく、制限された権限でのログインしているからです。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/84474/2005d272-58eb-49f0-d8ae-4b5ed736b5b0.png)

上記の図の例は、あるユーザーがPrism Centralにアクセスする際の動きを示したものです。ユーザーはSSPが連携しているディレクトリサービスの登録ユーザーとしてログインを試みます。Prism Centralの画面に入力したクレデンシャルは、ディレクトリサービスの登録ユーザーのクレデンシャルと同一です。ディレクトリサービスの登録ユーザーMilkであることが確認できた場合には、次にSSPのいずれかのProjectに所属しているか否かを確認します。

SSPのいずれかのProjectに所属していることが確認できると、ロールも自動的に確認できます。なぜならProjectに所属していると言うことは、Projectに対してMilkをアサイン時に、システム管理者・SSP管理又はProject AdminによってRoleも設定されるからです。これにより、こちらの例では、MilkにはConsumerのRole認可が行われます。以後、MilkはConsumerのRoleに基づくSSPでの操作が許可されます。

このように、Prism CentralのUIは、ログインしたユーザー権限によってアクセス可能なリソースを変えており、SSPユーザーは、基本的にVMに関連する操作のみが可能となっています。以下はその1でも紹介したシステム管理者とSSPユーザーのロールの抜粋です。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/84474/d93a76e7-55c3-99a0-634f-1ccc1abe2c8d.png)

###システム管理者でログインした際のPrism Central UI
SSPユーザーでPrism Centralにログインする前に、まずは、システム管理者でログインした際のPrism Central UIを見ておきます。システム管理者でログインした場合、通常はPrism Centralで管理しているクラスター群のアラートやヘルス等のダッシュボードが表示されます。
![スクリーンショット 2018-12-26 23.04.27.png](https://qiita-image-store.s3.amazonaws.com/0/84474/5222a75c-6c12-8dee-e4c8-0a915882522f.png)

また、左上の横棒が4本並んでいるメニューをクリックすると多くのメニューが見えていることがわかります。仮想化インフラストラクチャの管理メニュー、セキュリティやXi Leapを含むバックアップ・DRで利用するリストアポリシー等を管理するメニュー、Prism Centralで管理下にあるクラスターのハードウェア情報、それらのイベントやアラート情報、リソース管理や最適化メニュー、需給予測等のメニュー、プロジェクトやロール、ユーザーの管理メニュー、CalmやKarbonなどの拡張機能へのメニューなどです。
![スクリーンショット 2018-12-26 23.05.10(2).png](https://qiita-image-store.s3.amazonaws.com/0/84474/0481430f-6bd8-ef22-1f5e-c36fba1593a1.png)

また、左下に目をやると歯車アイコンに`Prism Central Settings`と表記があるように、Prism Central全体の管理を行うためのメニューも表示されていることがわかります。

こちらのメニューでは、Prism Centralの全般設定、ラインセンス設定、SSPユーザーではなく、Prism Centralのローカルユーザー管理、アラート発生時のメール設定などの設定を行うメニューが表示されています。
![スクリーンショット 2018-12-26 23.05.38.png](https://qiita-image-store.s3.amazonaws.com/0/84474/34c5746e-b786-76ed-6703-14aa0e1dbdef.png)

###SSPユーザーでログインした場合のPrism Central UI
一方でSSPユーザーで同じPrism Centralにログインしてみます。こちらの画面がSSPユーザーでログインした際に表示されるトップ画面になります。このログインユーザーは、今回の環境にあるActive Directoryにユーザー登録され、デフォルトで定義されているビルトインロールである`Consumer`をマッピングしているユーザーでログインしています。
![スクリーンショット 2018-12-26 23.06.20.png](https://qiita-image-store.s3.amazonaws.com/0/84474/ffd27fa3-e4c2-be84-feb9-4865a60626f8.png)

このビルトインロールの`Consumer`は、その他のSSPユーザー用のビルトインロールの中では比較的多くの権限が付与されているロールとなります。しかし、以下のように、システム管理者でログインした際のメニューと異なり、表示されているメニューが少なくなっているほか、左下にあった歯車アイコンに`Prism Central Settings`の表示もなくなっています。
![スクリーンショット 2018-12-26 23.06.37.png](https://qiita-image-store.s3.amazonaws.com/0/84474/32c579d3-6ca3-c710-55a8-98a89b05478c.png)

##SSPユーザーのVM作成操作
その2で述べたとおり、SSPユーザーのVM作成は、AWSのAMIやAzureのAzure Imageに相当するカタログから行います。そしてSSPにおけるVM作成はカタログのみからしか行うことができないこといついても既に述べたとおりです。また、SSPのカタログに登録可能なイメージは、VMテンプレート、ディスクイメージ、ISOイメージの3種類があり、いずれのイメージをVM作成に利用するかで、VM作成の操作が大きく異なることも紹介しています。SSPのVM作成における、この3つのイメージの使い分けは、以下のようなフローを並べてみることで整理できます。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/84474/40a8186c-26a5-4508-08d4-09595e51b110.png)

大きな分岐としては、VMテンプレートの利用有無です。VMテンプレートは、既にインストール済みのVMをスナップショットのようにカタログのイメージに保存し、そのカタログを利用してVMを作成する際に利用されます。この場合、VMテンプレートの元となったVMにインストールされたアプリケーションやOS上の設定をそのまま利用するだけでなく、vCPUやメモリ、ストレージ容量についても基本的にはVMテンプレートで定めされているものをそのまま使うことになります。

このような既にインストール済み、設定済みのVMを利用したくない場合は、OSのイニシャルインストールが可能なISOイメージを選択するか、VMテンプレートイメージを利用する場合とISOイメージを利用する場合の丁度中間の操作で利用可能なディスクイメージを利用してVMを作成します。

###VMテンプレートを利用する場合
SSPユーザーでSSPにログインしてCreate VMメニューからでVMの作成を行っていくわけですが、その中でVMテンプレートからのVMをデプロイする場合は、「VM Template」を選択してVMの作成を開始します。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/84474/2edf82e3-0027-1572-8fc4-e9976c3c0347.png)

カタログに追加済み・作成済みのVMテンプレート一覧から、テンプレートの作成日、vCPU数、ディスクサイズ、メモリを参照して、作成するVMの元となるテンプレートを選択します。以下の画面ではテンプレート名「CAT-SSP-WS2016-NO-CUSTOM」を選択している様子です。選択されたVMテンプレートは青色でハイライトされます。
なお、VMテンプレートからのVMデプロイを選択時はVMテンプレートのみが選択可能で、カタログに追加されているISOイメージやディスクイメージは選択できません。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/84474/d27940db-cfd4-0b88-f423-b162ea7404a0.png)

VMテンプレートを選択してNextボタンを押すと、VMの構成画面に遷移します。ここではデプロイするVM名などを入力していきます。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/84474/7a4106a9-cdec-f25f-eea3-7c4c392bb412.png)

なお、VM作成時に必要な項目はある程度UI上に表示されていますが、既に1つの完成されたVMからVMテンプレートとして構成されているため、ISOイメージやディスクイメージからのVMデプロイ時と異なり、ディスクの構成はVMデプロイ時には変更できません(ただし、VM作成後に変更することは可能です)。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/84474/8395d9a0-dfa4-8dc2-400c-d1750026e058.png)

最後に利用するネットワークを選択します。既に紹介しているとおり、利用可能なネットワークはあらかじめシステム管理者が設定したものだけが選択可能になっています。すべてのProjectにすべてのVLANが同一に設定されるわけは無く、Projectの作成時に、システム管理者によって利用可能なVLANが個別に割り当てられています。完全に排他割り当てというわけではなく、他のProjectで利用可能なVLANを共通して利用することも可能です。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/84474/84bad91b-56c0-00bd-0c6a-6e7eeda82bac.png)

基本的にVMテンプレートからのVMデプロイでは、セルフサービスにおいてvCPU、メモリ、ディスク構成操作を一切行わず（または意識せず）に高速またシンプルなVM作成方式ですが、`Advanced Settings`で`Manually configure the CPU and Memory for this VM`にチェックを入れると、VMデプロイ時にオプションでvCPUとメモリを変更することも可能です。

###ISOファイル及びディスクイメージを利用する場合
VMテンプレートからのVMをデプロイ時と同様にSSPユーザーでSSPにログインしてCreate VMメニューからでVMの作成を行っていきます。ISOファイル及びディスクイメージを利用するため、Disk Imagesを選択してVMのデプロイを開始します。ISOファイルからのVMのイニシャルインストールでもこちらを選択します。ここではISOファイルを利用したVMのイニシャルインストールの操作を見ていきます。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/84474/dfc739e9-835e-6e7c-d0cf-840114c97620.png)

VMのイニシャルインストールは、OSのインストールに必要な複数の仮想CD-ROM及びディスクを利用して行っていきますが、まずはOSインストールに必要なISOファイルを選択します。AHVでの利用を前提としているためWindows OSをインストール場合はOSのISOファイルとVirtIOドライバが格納されたISOファイルを選択、Linux OS等をインストールする場合は、各ディストリビューションのISOファイルを選択します。今回はWindows OSをインストールする場合を例にとって紹介します。
以下の例では、CAT-ISO-WIN10とCAT-ISO-VIRTIO113の2つのファイルを選択した状態です。選択されたカタログ項目は、青くハイライトされ、チェックマークが入ります。ISOファイルを選択した場合は、TYPEがCDROMになっていることを確認します。選択を解除する場合は、もう一度対象のカタログをクリックするだけで解除が可能です。
なお、これらのISOファイルはあらかじめカタログに登録しておく必要があります。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/84474/632f4467-6d5a-b352-54e9-ec3b34132aa0.png)

ISOファイルを選択し、Nextボタンを押すとVMテンプレートからのVMデプロイ時と同様にVMの構成画面に遷移します。VM名称を設定していきます。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/84474/b0360f23-9108-b5b9-e00d-0fe106d098fe.png)

次に、OSをインストールするディスクを設定していきます。既にこちらのディスク構成の設定では、先の画面で選択したISOファイルがCD-ROMに挿入された状態で追加済みになっています。そして、VMテンプレートからのVMデプロイ時と異なり、ディスク構成のUIには`+ New Disk`と`+ New CD`と言う項目が表示されており、追加でディスクやCD-ROMを追加する操作が可能になっています。OSをインストールするディスクを設定します。

`+ New CD`でCD-ROMも追加することができますが、Prism ElementなどでPrismのシステム管理者がVMを作成する際にImage ServiceからのISOファイルを選択しての追加操作と異なり、SSPではImage Serviceは利用できず、カタログに登録されているファイルのみが操作可能であるため、こちらの操作は、空っぽの仮想CD-ROMドライブを追加するだけの機能となっています。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/84474/902ecaa2-186c-7f06-eb7f-9e3e55954a1b.png)

VMテンプレートからのVMデプロイ時と同様にネットワークを選択します。ネットワークの選択は、VMテンプレートからのVMデプロイ時とISOファイル及びディスクイメージを利用したデプロイ時の違いはありません。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/84474/594468ab-1004-cb1b-decb-5a91c3fc67b7.png)

最後にCPU及びメモリを設定します。`Advanced Settings`で`Manually configure the CPU and Memory for this VM`にチェックを入れvCPUとメモリを設定します。ISOファイル及びディスクイメージを利用したデプロイ時は、比較的vCPUやメモリを個別に設定するケースが多い想定ですが、こちら何も設定しなかった場合は、デフォルトで1vCPUと1GiBメモリが設定されます。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/84474/ec334f86-4ce1-9402-8f53-8971789e9391.png)

なお、vCPUの設定について1つ注意点があります。これはISOファイル及びディスクイメージを利用したデプロイ時に限らず、SSPでVMをデプロイした際の共通的な仕様としてSSPユーザーによるVM構成時には、vCPUの設定にvCPUあたりのコア数の設定が省略されます。そのためSSPにおけるCPU設定では、常に1つのvCPUは1コアのものが設定されます。

Windows Server系やLinux系については問題がでないケースが多いのですが、WindowsクライアントはWindowsの仕様としてCPUソケットが2までしか認識しないため、例えば、SSPで4つのvCPUを割り当てた場合、先ほど述べたSSPの仕様から、仮想ハードウェア上から見ると4つのソケットのCPU、各CPUは1コアのものが設定されたと認識され、WindowsのクライアントOSからはそのうちの2ソケット分までのみを認識して起動してしまいます。

多少煩雑な対応となりますが、SSPにおいてWindowsのクライアントOSを利用し、かつvCPU数を多く必要とする場合は、個別にPrismの管理者にVMの構成変更を依頼する必要があります（一度デプロイされたVMは、Prismのシステム管理者からも見えるためPrism ElementやPrism Centralのシステム管理者画面を通じてVMの構成を変更することが可能）。

###VMデプロイ後のVM操作
VMをデプロイした後は、Prismのシステム管理者として利用していた場合と同様にHTML5ベースのVNCによるVM操作やOSインストール作業を行っていきます。

VMの構成画面でSaveを押し、VMをデプロイしたVMは自動的に電源がONになります。SSPの画面左ペインのVMsから作成したVMをクリックし、Consoleタブをクリックするか、メニュー上部にあるLaunch ConsoleでVMのコンソール画面を開きます。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/84474/d04b0126-60dd-07e7-0f5d-979d3c14b32b.png)

Consoleタブをクリックをクリックした場合は、操作中のブラウザ内に、メニュー上部にあるLaunch Consoleをクリックした場合は、ブラウザのポップアップウィンドウにて、VMのコンソールが表示されます。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/84474/3d478d42-0cc8-7f6a-d72d-a3568b05b5b5.png)

#まとめ
ここまで、その3では、VMの作成方法を中心に紹介をしてきました。SSPはユーザーレベルでVMを操作するため、IaaSなどと同様に、システム管理者のVM操作とは異なる点がいくつかあります。ユーザー視点で見ると、SSPで可能なこと不可能なことの違いを点を理解することでスムースな利用が可能となり、システム管理者視点で見ると、ユーザーにSSPを提供する際の注意事項や必要に応じた個別に対応を把握しておくことでスムースなサービス提供が可能です。

以下、その3のまとめです。

* SSPユーザーによるVMのデプロイは、カタログを通じてのみ可能
* SSPユーザーが利用可能なカタログは、PrismのAdmin及びSSP Adminなどのシステム管理者のみが追加可能
* SSPユーザーはVMのデプロイ方法としてVMテンプレートからのデプロイ及びISOファイル及びディスクイメージを利用した方法を選択可能
* VMを即時に利用したい場合はVMテンプレートをOSをイニシャルインストールする場合はISOファイルを利用した作成方法を選択
* SSPでは1つのCPU設定は常に1コア設定となる

#POST SCRIPT
さて、NutanixのSSP（Self Service Portal）再入門（その3）をお届けしてきましたが、いかがでしたでしょうか。システム管理者として利用している際にはできたことが、ユーザーレベルではできなくなることについての不便さを感じるケースもあるかもしれませんが、多くのIaaSでは、ユーザーレベルで仮想化基盤を利用する際に、システム管理者と同等の権限を有することはありません。また、パブリッククラウドなどのIaaSサービスと異なり、オンプレミスでの運用を主なユースケースとして想定していることから、パブリッククラウド等のIaaSとは一部異なる概念もあり、SSPの利用においてはその点を理解する必要があります。

ここまで、SSPの構成、ユーザーレベルでのVMの作成を見てきましたが、その4では、主にVMデプロイ後の運用や、ここまでまったく触れていなかったCalmについても少し触れていきたいと思います。