Prism Centralの活用その6（仮想マシンテンプレートをメンテナンスする/その2）

前回は、マスターVMから仮想マシンテンプレートの作成と展開方法をご紹介しました。

正直なところ、もともとの仮想マシンをクローンするときの画面とほぼ変わらないので、ある意味とっつきやすかったかと思います。

では、この仮想マシンテンプレートですが、Windowsであれば定期的なアップデートや関連ソフトウェアのパッチ適用など、マスターに対する定期的なメンテナンスが必要になるかと思います。

vSphereの場合、テンプレートか普通の仮想マシンかは、拡張子が「.vmx」か「.vmtx」かで切り替えられているだけでしたが、Nutanix+AHV環境の場合、仮想マシン環境情報は、ファイルでは管理されていないので、ユーザー側で自由に切り替えることはできません。

その代わりに、テンプレートのメンテナンス機能が用意されています。

今回は、このメンテナンス機能を利用し、テンプレートに入れていたゲストOSのアップデートを行ってみましょう。

まずは、Prism Centralの「Templates」を開き、メンテナンスしたい仮想マシンをクリックします。詳細画面の「Actions」から「Update Guest OS」をクリックします。

ここでは、初めてテンプレート化したものしかないので、「Initial Version」しか選択できませんので、そのまま「proceed」で進めます。

次に、説明画面が表示されます。ここでは、メンテナンス完了までの流れが表示されます。要は、テンプレートから仮想マシンが展開され、その仮想マシンにメンテナンスを行います。メンテナンスが完了したら、完了処理を行うことで、メンテナンスされた新しいバージョンとしてテンプレートに保存される（今までのメンテナンス前のバージョンも履歴として残る）旨が表示されます。続けて「Proceed」をクリックします。

「Proceed」をクリックすると、メンテナンス用の仮想マシンが展開されます。展開された仮想マシン名が画面に表示されますので、その仮想マシン名をクリックし、仮想マシン一覧画面に移動し、パワーオンした後にコンソールを開きメンテナンスを行います。

ここでは、Windows Updateを行い、TeraTermをインストールし、マスターのメンテナンスを完了させます。

メンテナンスが終わった仮想マシンは、きちんとOSからシャットダウンしましょう。

再び、Prism CentralのTemplates画面から、メンテナンスが完了したテンプレートを選択し、「Action」から「Complete Guest Update」をクリックします。

もし、メンテナンスが必要なかった場合や、あまりないとは思いますが、テンプレートから展開されたメンテナンス用の仮想マシンを誤って削除した場合などは「Cancel Guest OS Update」をクリックしましょう。

続いてメンテナンスが終わった仮想マシンの名称やメモを入力する画面が表示されます。必要に応じてメモは入力を行ってください。

下側には、今回反映する変更を、ユーザーがすぐに使えるテンプレートとしてActiveにするかのチェックボックスがあります。その後テストなどを行い、リリースまで時間を必要とする場合は、「Yes, set this new version as active」のチェックは外しておきましょう。

必要事項を入力したら、「Complete Update」をクリックします。

反映されると、画面左の「Versions」を開いてみましょう。

最初にテンプレートに登録したものが、「Initial Version」として扱われ、メンテナンスを行いそれを反映させるたびに、このバージョンが増えていくという流れになります。

先ほどのウィザードで「Yes, set this new version as active」にチェックを入れると、そのバージョンが、テンプレートから展開されるバージョンとなりますので、もし、違うバージョンをテンプレートから展開できるようにしたい場合は、そのバージョンを選択し、「Set as Active」をクリックします。この画面から不要なバージョンの削除も可能です。例えば1年前のWindows Updateのメンテナンスされたテンプレートなどは誰も使わないと思いますのでそう言った場合は、不要なテンプレートとして削除が可能です。

これで、テンプレートのメンテナンスは完了です。

テンプレートの運用ですが、Windowsの場合、初めにSysprepをしていないバージョンのものを最初に登録し、その後Update OSで、Sysprepを実行しシャットダウンしたものを別のバージョンとして登録しActive化しておきましょう。
Windows Updateで新規パッチを適用する際は、Sysprepしていないバージョンをメンテナンス用として利用し、その仮想マシンにパッチなどを適用しSysprepしシャットダウンしたものを新しいバージョンとしてことで、メンテナンス時のSysprepの時間を短縮することも可能となります。

気を付けておくべき点としては、ユーザーからすると、テンプレートから展開する際にテンプレートのバージョンは選択できず、Activeになっているバージョンが自動的に展開される点です。いくらメンテナンスを行っても、そのバージョンを「Active」にしていなければ、実際にはテンプレート展開時に利用されませんので、注意してください。

Prism Centralの活用その6（仮想マシンテンプレートを作成・展開する/その1）

vSphere環境(vCenter Server)を利用しているユーザーからよく聞かれる質問として、

1. 「仮想マシンクローンをしたら、Sysprepって自動でされるんですか？」
2. 「仮想マシンをテンプレート化して、仮想マシン一覧表示から消したいのですけど？」

という質問をよくいただきます。

この辺り、従来のPrism Elementだけでは完全にカバーしきれないところがあったのですが、Prism Centralのテンプレート機能ができたことで、通常運用する仮想マシンと別の管理のマスターVM（ゴールドイメージ）として管理ができます。

今回は、まずテンプレート機能の基本を見ていきたいと思います。

＜テンプレートのつくり方＞

テンプレートのつくり方は、簡単です。
Prism Centralから、テンプレート化したい仮想マシンをVMs画面で選択し、「Create VM from Template」をクリックします。

次にテンプレートの名前とメモを入力します。
併せて、デフォルトのカスタマイズ設定が可能です。Windowsであれば、Sysprepの応答ファイル、Linuxの場合は、cloud-initのファイルを記載します。

実際にテンプレート時にカスタムファイルを指定しなくても、テンプレートから展開する際には、個別でカスタムファイルの指定ができます。ここでは、テンプレート展開時にデフォルトで表示されるカスタムファイルが表示される内容となります。

最後にサマリーが表示されますので、そのままSaveをクリックします。

裏の動作を見ていると、テンプレートを作成すると、Recovery Pointが作成されますので、その時点のスナップショットが内部的に作成されていることがわかります。

実際にテンプレートの元になった仮想マシンのRecovery Pointには、テンプレート用に作成されたRecovery Pointが表示されていることがわかります。

なお、テンプレートの元になった仮想マシンは、削除しても問題ありません。

＜テンプレートからの展開＞

では、実際にテンプレート化した仮想マシンを展開してみましょう。
Prism CentralのVMsから、「Create VM from Template」をクリックし、展開したいテンプレートを選択し、Beginをクリックします。

次に仮想マシンの表示名や数量などを入力する画面が表示されます。

「Advanced Deploy」をクリックすると、仮想マシンのスペックやVLANの割り当て変更などができるようになります。

Advanced Deploy画面も見てみましょう。

スペックの変更ができることがわかります。ここでは、Memory Overcommitの設定変更はできないようになっています。「Next」をクリックして次の画面を確認してみましょう。
展開台数を複数台展開する場合は、Number of VMsで必要な数量を入力可能です。

ここでは、仮想マシンのドライブやNIC構成が確認できます。ディスク構成は、この画面では変更ができないようです。NICに関しては、NICの追加や既存NICのVLAN変更が可能です。

続いては、タイムゾーン設定やストレージポリシーの設定ができる画面となります。ストレージポリシーとゲストOSのカスタマイズ項目以外は、特に設定変更できないようです。

この後、サマリー画面が表示され、「Deploy」をクリックすると、仮想マシンが展開されます。

無事に仮想マシンが作成されました。

作成された仮想マシンは、通常の仮想マシンと同じように、スペックの変更やディスクの追加アタッチなども可能です。

テンプレートの追加とテンプレートからの展開は、非常に楽にできることがよくわかりました。基本中の基本の操作だけをご紹介しましたが、実際には、いつ作成したかわからない古いテンプレートは結果使われなくなりますので、次回は、テンプレートのメンテナンスについてご紹介いたします。

 

Prism Centralの活用その5（他の仮想マシンの仮想ディスクをマウントする）

例えば、運用中の仮想マシンがWindows Updateなどの処理によりOSが正しく起動しなくなった場合、vSphere環境では、別の正常にOSが稼働する仮想マシンから、OSが起動しなくなった仮想マシンの仮想ディスクをデータストア参照を行いマウントすることができます。

Nutanix+AHVの環境であってもこのような操作はできないわけではないのですが、複雑であり従来はイメージサービス経由でしか操作ができないという時代から、acliコマンドを使って

「 vm.disk_create <仮想マシン名> clone_from_vmdisk=<VM名>:scsi:0」

といったように、元の仮想マシンがマウントしているディスクをクローンしてマウント指定することができるようになりました。

とはいえ、コマンドでしかできないという点で（CVMにSSHアクセスをしないといけないので）あまりユーザーフレンドリーには捉えられていないという課題が残っておりました。

実は、この別の仮想マシンが利用している仮想ディスクをクローンして他の仮想マシンに割り付けるという操作は、Prism Centralであれば、GUI操作で設定が可能です。

以下のような点でメリットがあるように思われます。

• OSやシステムが起動しなくなった仮想マシンを、別の操作用仮想マシンからディスクをマウントし、必要データをサルベージ（回収）する
• ファイルサーバーなどでユーザーが誤って消したファイルがある場合、その仮想マシンのファイルが削除される前のスナップショットから仮想マシンをリストアし、リストアした仮想マシンの仮想ディスクを、稼働中のファイルサーバーからマウントし、ファイルをサルベージする

要は、稼働している仮想マシンに、他の仮想マシンの仮想ディスクを割り付けてデーターだけを引き抜くときに利用できます。

vSphere環境と異なる点として、Nutanix+AHV環境の場合、マウントしたい仮想ディスクのクローンを一度作成し、そのクローンをマウントするという点です。（クローン自体はストレージのポインターベースで行われるのでクローンに対して時間がかかったりストレージの容量が大きく消費することはありません）

ここでは、OSが起動しなくなった仮想マシン「DAMAGE-VM」の仮想ディスクを、「MAINTENANCE-VM」からマウントし、内部のデータを取得するというオペレーションでご紹介したいと思います。

今回はともにWindows OSをベースにしていますが、オペレーションとしてはLinuxであっても一緒です。ただしLinuxの場合、LVMを使っている場合は、OS起動後のマウントに対して気を配る必要があるように考えられます。

まずは、Prism Centralの画面から、メンテナンスを行う「MAINTENANCE-VM」のUPDATEを行います。

仮想マシンのスペックは変更する必要がありませんので、そのまま「Next」をクリックします。

次の画面で仮想ディスクやCDROMドライブの一覧が表示されます。

現在、この仮想マシンには、仮想ディスクは1本しか搭載されていないことがわかります。

「Attache Disk」をクリックし、ディスクを追加します。

ここでディスクを追加するのですが、Operationで「Clone from another VM Disk」を選択します。

そうすると「Search by VM Name」項目が表示されますので、マウントしたいディスクを搭載している仮想マシン（ここでは、DAMAGE-VM）を選択します。

選択した仮想マシンに複数の仮想ディスクが搭載されている場合、どのディスクバスのディスクをマウントするかを選択します。この例では、scsi:0番の仮想ディスクをマウントしていることがわかります。

ディスクをマウント設定した後、Saveをクリックします。

これで、既存ディスクに対して1つ新たなディスクが接続されたことがわかります。

このままNext、Next、Saveの順にクリックし、仮想マシンの構成を終了します。

では、ディスクを操作する側である、MAINTENANCE-VMを起動します。

Windowsの場合、「ディスクの管理」を開き、ディスクが正常にマウントされているかを確認します。まれに、ディスクがオフラインになっている可能性がありますので、その際は、ディスクをオンラインに変更します。

オンラインになると、エクスプローラーでドライブが見えます。

ドライブレターがこの場合は、「F」ドライブがマウントしたディスクのCドライブになります。

これで必要なファイルをエクスプローラーから取得するなどのオペレーションが可能です。逆にOSが起動しなくなった場合などに、必要なファイルをマウントしたディスクに入れる場合は、必要なファイルを入れたのち、本来起動すべき仮想マシン側で、メンテナンス側で利用した仮想ディスクを「Clone from another VM Disk」で、さらにクローンして割り当ててください。これは、今マウントしているものがクローンであり、マウントした仮想マシンの実態のディスクではないためです。クローンしたディスクに編集を加えているので、本来お仮想マシンで操作する際には、操作したディスクをさらにクローンして本来の仮想マシンに再割り当てする必要があります。

Prism Centralの活用その4（RBACで操作と見える範囲の権限設定・その3）

前回までにRBACの設定とユーザーごとに操作できる画面が異なることを確認しました。

前回の課題であった剛田武（ジャイアン）は、仮想マシンのパワーオン・オフの権限すらなく、仮想マシンのオペレーションができない点です。

ジャイアンに仮想マシンのコンソールを渡すと何をされるかわからないので、最低限障害が発生した際に仮想マシンのリセットや電源入り切りができる権限だけを付与するというシナリオで進めたいと思います。

まずは、管理者権限で、Prism Centralにログインし、「Admin Center」→「IAM」→「Roles」画面に移動します。

そこから、「Create Role」で「From existing role」を選択します。

ロール部分に「Virtual Machine Viewer」と入力しNextをクリックします。

一部の権限がコピーできない旨が表示されますが、そのまま「Continue」をクリックします。

ガイド表示が出てきた場合は、Skip for nowをクリックしましょう。（ガイドを見たい場合は進めてもらっても構いません）

このままでは、先ほどジャイアンに適用していたVirtual Machine Viewer権限なので、仮想マシンの電源操作ができません。ここで、仮想マシンの電源操作関係の権限を追加していきます。

まずは、左上の「Role Name」を「Holdings System Operator Role」に変更します。
Role Nameの下側「Select operations to grant access」の下にあるリストから「AHV VM」の+ボタンをクリックします。

右側の「AHV VM」のリストも展開しましょう。

左下のAHV VMから以下の権限情報を探して、「+」ボタンをクリックします。

以下の項目を探し、＋ボタンを押して追加します。

• ACPI Reboot Virtual Machine
• ACPI Shutdown Virtual Machine
• Allow Virtual Machine Power Off
• Allow Virtual Machine Power On
• Allow Virtual Machine Reboot
• Allow Virtual Machine Reset
• Guest Reboot Virtual Machine
• Guest Shutdown Virtual Machine
• Power Cycle Virtual Machine
• Power Off Virtual Machine
• Power On Virtual Machine
• Reset Virtual Machine

追加する際に、さらに必要な権限がある場合は併せて表示してくれます。Doneをクリックしましょう。

追加を確認したら、右側の一覧に追加されることが確認できると思います。

追加が完了したら、「Save」をクリックします。

一部のオペレーションで権限が不足していると表示されますが、ホストアフィニティなどは、権限付与しませんので、そのまま「Save」をクリックします。

Rolesの一覧表示画面に戻りますので、作成したRoleが存在しているかを確認します。デフォルト20行しか表示されませんので、ページをめくるか表示数を60に変更するなどして探してみてください。

次に「Authorization Policies」画面から、ジャイアン用のポリシーである「System Operator」をActionボタンから「Edit」をクリックします。

Policy名称のところに、先ほど作成した「Holdings System Operator」を入力し選択します。

スコープやユーザー設定がリセットされるけど良いか？というメッセージが表示されますので、「Continue」をクリックします。

そのまま続けるので、Nextをクリックします。

続いてスコープを設定します。（前回と同じくAll Entity Typesで、In Categoryを選択し、ジャイアンが操作するカテゴリであSystem Operatorを選択）設定後「Next」をクリックします。

続いてユーザーの設定を行います。こちらでは、ローカルユーザーの「takeshi.goda」を選択し、「Save」をクリックします。

これで、設定は完了しました。

再度別のブラウザから、ジャイアンのアカウントでログインします。

実際の仮想マシンの詳細画面に行くと仮想マシンの再起動ボタンなどが表示されています。

仮想マシン一覧画面のActionメニューから見ると、きちんとシャットダウンボタンも表示されていることがわかります。

これでジャイアンに対して、仮想マシンのシャットダウンやリセットなどの権限を付与することができました。別途仮想マシンコンソール操作権を割り当てたい場合は、「Access Console Virtual Machine」を追加すれば仮想マシンの画面も見ることができるようになります。

デフォルトで存在しないロールの場合デフォルトのロールをベースに足りないものを追加するということができ、個別で細かな権限設定ができることがわかったかと思います。

ロールを新規で作成することも可能ですが、その場合、この多数のオブジェクトから必要なものを選択するのは非常に手間がかかります。例えば仮想マシンの電源操作だけの権限であっても、その場合仮想マシンが属するクラスターのView権限が必要など、親子関係があるオブジェクトの参照権限が正しく設定されていないと、操作したい対象物が表示されないことがあります。

そういった複雑性を考えると、既存ロールからやりたいことが近いものを選択し、そこから詳細の権限操作の必要有無を確認しながら権限付与・はく奪するのが望ましいと考えられます。

Prism Centralの活用その4（RBACで操作と見える範囲の権限設定・その2）

前回までに、RBACで必要なリソースの割り当ての設定を行ってきました。

今回は実際にユーザーごとにどのように見え方が変わるかを確認してきたいと思います。

まずは、6VMの管理者権限を持つののび太でログインしてみましょう。

ログイン方法は、Prism Centralのログイン画面（管理者が使うもの）と同じログイン画面からログインします。

 ▼のび太でログインした際の画面

のび太でログインした場合、仮想マシンは6台表示されていることがわかります。

のび太は管理者のためNGTのインストールやOVAエクスポートなども操作できるようになっています。

▼スネ夫でログインした際の画面

見える仮想マシンが2台に制限されていることがわかります。
また、左側のメニューものび太に比べて随分と少なくなっていることがわかります。このメニューで表示されるものはロールに合わせて権限があるものが表示されます。オーソライズドポリシーで設定されたカテゴリに属していないリソースは、表示されないため実際には、クラスターと仮想マシンしか表示されません。

▼仮想マシンの詳細画面

仮想マシンのコンソールや電源関係のオペレーションも可能であることがわかります。一方でのび太の画面で表示されていた、NGTのインストールやOVAエクスポートなどの画面は表示されていないことがわかります。

▼剛田武（ジャイアン）でログインした画面

Virtual Machine Viewer権限で5VMの仮想マシンが見えていることがわかります。一方左側のメニューはスネ夫にもまして、表示されるメニューが減っていることがわかります。

▼仮想マシンの詳細画面

ジャイアンの場合、仮想マシンを見るだけの権限のため、パワーオン・オフなどの操作や仮想マシンコンソールの画面が表示されないことがわかります。

以上でユーザーごとに見えるオブジェクト（仮想マシン）や操作できる内容が変わったことがわかります。これがRBACの機能です。

一方で、ジャイアンは、一切のオペレーションができなくなっているのは、今回のオペレーターとしての権限としては不十分であると考えられます。

ロールとしてテンプレートとして用意されているものは一般的によく使われる権限のため、そのまま利用できるケースが多いかと思いますが、今回のようにジャイアンに対して権限を追加付与したい場合も出てくるかと思います。

次回は、ロールのカスタマイズによる個別権限の付与を行ってみたいと思います。