Self Service Restore (SSR)の注意点

Nutanixのファイルベースのリストア機能、Self Service Restore（SSR)は大変便利な機能です。ただ、この機能を使う上で押さえておくべき点もありますので、今回は注意点をお伝えします。

その１

SSRを利用するためには、仮想マシンとNutanixの「CLUSTER VIRTUAL IP ADDRESS(Cluster VIP)」2074/TCPで通信ができる必要があります

これは、NGTの仕様にもかかわるところなのですが、仮想マシンにインストールされた
Self Service Restore GatewayがNutanix Cluster VIPにアクセスし情報を取得するため、仮想マシンとNutanixクラスターの管理IPのあいだで、2074/TCPの通信が行われます。
DMZに配置するサーバー等では一部セキュリティ上の課題が出てくるケースもありますので注意が必要です。

その２

SSRからマウントしたドライブ読み取り専用ではマウントされない

これは、実際にファイルのリストアをする際に、スナップショットをマウントしたドライブにもファイルの書き込みなどができてしまいます。もちろん、誤ってファイルを上書きしたり消したりしてしまっても、そのディスクをアンマウントして再度スナップショットをマウントすれば元に戻るのですが、現状のドライブとスナップショットをマウントしたドライブは基本同じマシンのディスクのため勘違いしやすいので、ファイルリストア作業時は注意が必要です。

その３

PRISM側で仮想マシンで「Enable Nutaix Guest Tools」と「Self Service Restore (SSR)」のチェックを有効にしておくこと

こちらは、NGTのメディアマウント機能とNGTやSSRを有効にするチェックボックスが同じ画面にあるため、NGTのインストール完了後、まとめてチェックを外してしまうケースがありますが、上記の2つのチェックを外すと、SSRが正常に起動しません。仮想マシンをクローンした場合も元の仮想マシンのNGTの状態は保持されませんので、クローン完了後、個別にNGTとSSRの機能を有効にする必要があります。

（参考）Manage Guest Toolsの設定

尚、Self Service Restore(SSR)が有効になっていない場合、SSRのポータル画面でログインすると「Error executing command: File Level Restore capability is not enabled」というメッセージが表示されます。

（参考）

その４

SSRポータルにドメインユーザーでログインする場合、「DOMAIN\Username」形式で入力する。ドメイン名、ユーザー名も大文字・小文字の判断が入ることに注意

これは"Self Service Restore (SSR)が便利　その３"の項でも紹介をしましたが、「Username@DOMAIN」という形式ではログインができません。
また、ドメイン名やユーザー名も大文字小文字を判断していますので、Active Directory側で入力された内容を正しく反映する必要があります。（例えば、ドメインのアドミニストレーターユーザーの場合「DOMAIN\Administrator」という表記になります。

その５

対応OSは、WindowsOSのみ

これは、表記のとおりです。Linuxはまだ対応していませんので、Sambaでファイルサーバー等を作成している場合は、注意が必要です。

その６

vSphere環境の場合は、仮想マシンオプションに「disk.enableUUID=TRUE」が付与されていること

こちらもご案内済みですが、スナップショットのディスクがマウントされますのでその際のトラブルをなくすためのパラメーターです。vSphere6であれば、基本Windows2008R2以上の仮想マシンを作成すると自動的にこのパラメーターは付与されると思います。


SSRが正しく動作しないと思ったら、まず上記の内容を確認してみましょう。

Nutanix Guest Toolsのメディアがマウントされない場合

Nutanix Guest Toolsは、Nutanix上で仮想マシンを動作させる場合、入れておいたほうが便利な機能が詰まったものです。
Nutanix Guest Toolsは、Nutanix上から、ISO Media Mountの機能を利用して仮想マシンの仮想CDROMドライブにマウントされます。

このメディアマウント機能ですが、仮想マシンの仮想CDROMドライブになにもメディアがマウントされていないにもかかわらず、「Guest Tools cannot be mounted as there not enough empty CD-ROM(s)」とメッセージが表示されメディアがマウントできないことがあります。

（参考）メディアマウント時のエラー

AOS5.0の場合、vSphereであっても、vCenter Serverとの登録を行っている場合、仮想マシンの構成を見ることができます。
ここで見ると、Disksの中にCDROMドライブが存在しないことがわかります。

（参考）仮想マシンのドライブを確認

ただ、仮想マシンにはCDROMドライブが搭載されていることがわかります。

（参考）仮想マシンから見たCDROMデバイス

さて、この現象に遭遇した際の対処法ですが、CDROMドライブがSATAで構成されているときにこの症状が出るようです。

vSphere Web Clientから仮想マシンを編集で開き、CDROMドライブの仮想デバイスノードを「SATA」から「IDE」に変更します。（仮想マシンはパワーオフしておく必要があります）

（参考）SATAからIDEへ変更する箇所

IDEに変更する際、チャネルを0:1や1:0など好きなチャネルに設定していただいてかまいません。（昔からながらで考えるとIDEディスクは、チャネル0:0で、CDROMドライブは1:0か1:1という時代もありましたが・・・）今回はIDEチャネルを0:1で設定します。

そのうえで、再度PRISMの仮想マシンメニューから、「Manage Guest Tools」をクリックし、「Mount Nutanix Guest Tools」のチェックをクリックしてもエラーメッセージが表示されません。

NutanixからISOをマウントする際に利用できる仮想CDROMドライブが、IDEでないとNGTはマウントできないということのようです。（AOS5.0.0.2にて確認）

もし、「Guest Tools cannot be mounted as there not enough empty CD-ROM(s)」
というメッセージに遭遇したら、他のメディアがマウントマウントされていないかの確認と、仮想CDROMドライブのバスがIDEになっているかを確認しましょう。

Self Service Restore (SSR)が便利 その３

前回までのSSRの活用目的や動作環境の確認を行いました。
では、実際にSSRを活用してみたいともいます。

まずは、デスクトップにある「Nutanix SSR」を開きます。
このプログラムは、Pythonで作成されており、ローカルの5000/TCPでリッスンしています。

ここで入力するユーザー名は、ローカルの管理者アカウントです。
ローカルのAdministratorの場合はそのまま「Administrator」と入力し、OSのパスワードを入力します。
ここで2点ほど注意点があります。それは、ドメインユーザーでのログイン時です。

1. ドメインユーザー時におけるログインの注意点は2点です。入力方法は、「DOMAIN\UserName」形式
2. ドメイン名、ユーザー名も大文字小文字が判断される

となります。
特に2点目は注意事項が必要です。ドメイン名も大文字文字を判断されます。
Windowsで操作をする場合、ドメイン名やユーザー名は小文字大文字を判断しないため、あまり気にしないケースが多いですが、SSRは明確に判断されます。

確認方法としては、該当の仮想マシンで「net localgroup administrators」コマンドを実行して、Administratorsグループに属しているユーザーの詳細情報を確認します。

（参考）net localgroup administartorsの結果

上記のルールに従い、大文字小文字を正しくした形で「ドメイン名\ユーザー名」でログインを行います。

（参考）TORITEN\SekiajiSekisabaユーザーアカウントを利用した場合のログイン時

ログインが正常に行われると、Nutanix側で取得したスナップショットの一覧が表示されます。ここから、マウントしたスナップショットの世代を選択します。

（参考）ログイン後のスナップショット一覧

選択すると、そのスナップショットで取得したドライブが表示されます。
マウントしたいディスクにチェックを入れ、確認後、Disk Actionからマウントを行います。

（参考）ディスクマウント方法

ドライブがマウントされると、操作をした仮想マシンにドライブがマウントされていることがわかります。尚、Cドライブだけマウントしたらドライブが２つ出てきていますが、これはWindowsの起動領域のパーティションが見えているためです。

あとは、実際にリストアしたいファイルをマウントしたドライブから選択し、ファイルをローカルのディスクにコピーすれば作業は完了です。

コピーが完了したら、先ほどのSSRポータル画面に戻り、「Mounted Snapshots」画面を開き、マウントしているディスクをチェックを入れ「Unmount」ボタンをクリックすれば、ディスクはアンマウントされます。

（参考）ディスクマウント情報確認とアンマウントの方法

SSRの利用は、これだけの手順です。
NGTのインストールからファイルのリストア、アンマウントまでの作業を一連でお伝えしましたが、非常に簡単な操作でファイルのリストアが可能であることと、仮想化基盤管理者と分離して特定のマシン管理担当者のレベルで作業が可能であることは、ユーザーからの要求に対するスピードアップと管理の効率化があがると思います。

Self Service Restore (SSR)が便利 その２

前回の項でSSRの概要をお伝えしました。
では、具板的にSSRの利用方法をお伝えします。

その前に、SSRが活用できる環境と条件を押さえておきましょう。

1. SSRを利用するには、NutanixのProライセンス以上が必要になります。
2. 対応しているゲストOSは、Windowsのみであり、Linuxには対応していません。
3. ASO4.5以上で作成されたスナップショットが対応可能です。
4. ESXi仮想マシンは、「disk.enableUUID=TRUE」パラメーターが有効になっている必要があります。
5. スナップショットをマウントする際にドライブレターを利用するため、ドライブレター文字列に余裕がある必要があります。
6. ボリュームグループはサポートされていません。RAID5やミラーボリュームなどのダイナミックディスクはサポートされません。
7. SATAディスク、仮想マシンスナップショットで取得された差分ディスクはサポートされません。

OSは、Windowsのみであること、NutanixのライセンスがPro以上が必要であることは重要な要件事項ですので、押さえておきましょう。

3点目は、スナップショットベースのバックアップソフトウェアやVMware DataProtection（VDP)などでも要求される事項です。仮想マシンオプションでパラメーターが入っていることを確認しておきましょう。（vSphere6.0でWindows Server 2012R2などで構成した場合、自動で入っていると思われます）

（参考）EnableUUIDの確認方法

また、Windowsのダイナミックディスクで複数の仮想ディスクを束ねて運用している場合、仮想ディスク単位で管理されているNutanixは、ディスクを束ねている状況を理解できないため利用不可であることを押さえてください。

（参考）セルフサービスリストアの要件と制限

https://portal.nutanix.com/#/page/docs/details?targetId=Web-Console-Guide-Prism-v50:man-file-level-restore-requirements-r.html

SSRの利用には、事前の作業が必要です。

作業１：対象の仮想マシンに対して、NGT（Nutanix Guest Tools）をインストールする
作業２：Data Protectionでスナップショットを取得する
作業３：SSRログイン用の管理者ローカルアカウントを作成（すでに存在している場合それを活用可能）

となります。

まずは作業1のNGTのインストール方法です。PRISM画面から仮想マシンを選択後、「Manage Guest Tools」をクリックします。

まずは、NGTインストールのために、「Mount Nutanix Guest Tools」を有効にし、メディアをマウントします。また、SSRを利用しますので、「Enable Nutanix Guest Tools」と「Self Sertvice Restore (SSR)」を有効にします。

■ 注意点 ■
NGTをインストールして、SSRを利用する場合、「Enable Nutanix Guest Tools」と「Self Sertvice Restore (SSR)」を必ず有効にしておく必要があります。この設定は仮想マシン単位であることと、クローンした仮想マシンはデフォルトで有効にはなりませんので、手動で有効にする必要があります。

NGTのメディアが仮想CDROMドライブにマウントされますので、Autorun機能を利用\するか、CDROMドライブの中の「setup.exe」からインストールを行います。

NGTインストール後、デスクトップにSSRのアイコンが出現します。

また併せて、NGTにかかわるサービスが登録・起動していることがわかります。

作業２は、スナップショットの取得作業です。すでに該当の仮想マシンをData Protectionでスナップショットの設定作業済みであれば、特に追加の作業は必要ありません。

（参考）スナップショットの取得設定と確認

作業３は、ローカルの管理者ユーザーが必要という話なだけです。ローカルのAdministratorユーザーをそのまま活用いただいてもかまいません。必要に応じてユーザーを追加します。
ローカルのユーザーを追加せずに、特定の仮想マシンだけのAdministrator権限をドメインユーザーに割り当てることも可能です。

この場合の用途は、仮想マシンのローカルアカウント出の管理者アカウントは、管理が煩雑になりますが、特定のマシンだけを管理者権限を渡すために、Domain Adminsを与えることはできないといった問題を解決することができます。

その場合は、権限をつけたい仮想マシンの「コンピューターの管理」を開き、ローカルユーザーとグループのグループの中から「Administrators」を右クリックし、「グループに追加」をクリックします。

（参考）コンピューターの管理

グループに参加しているユーザーの一覧が出ますので、追加ボタンをクリックし、「ユーザー、コンピューター、サービスアカウントまたはグループの選択」の画面で「場所」ボタンをクリックし、参加させたいドメインユーザーが所属するドメインまたはその配下のOUを選択します。

（参考）場所の選択

追加したいユーザー名を入力し、名前の確認をクリックし、ユーザー名情報が正しく取得できたことを確認し、OKをクリックします。
（詳細設定から検索してもよいです）

（参考）ユーザ名を入力し、名前の確認をクリック後OKをクリック

このスクリーンショットでは、「toriten.oita」ドメインに所属する「karaage」アカウント（ユーザー権限）をこの仮想マシンのAdministrators権限を不要されたことがわかります。
※karaageユーザーは、ドメイン全体ではUser権限ですが、この仮想マシンの中だけAdministraor権限が付与されることになります。

（参考）ユーザー追加後

では、次回に実際のSSR利用方法をご紹介します。

Self Service Restore (SSR)が便利 その１

サーバー仮想化で、仮想化の対象にするかが悩ましいところが、ファイルサーバーというエンジニアの方は多いのではないかともいます。

ファイルサーバーが大量のストレージ容量を消費するのもそうですが、この大容量のファイルをいかに手軽にバックアップをとるかとなると、今までの仮想化基盤で難しい側面がありました。また、仮想化環境におけるイメージバックアップソフトウェアでは、ファイルレベルのリストアを行うのが苦手であったり、複数の手順を踏まないとファイルのサルベージ（救い出し）ができないケースも見かけられます。

Nutanixにおいては、仮想マシンを素早くバックアップ状態を取得する、ストレージベースのスナップショット（Data Protection）がありますが。

これは、仮想マシンに紐づく仮想ディスクのストレージブロックを固める機能で、従来のバージョンからこのスナップショットベースで取得した任意の世代の仮想ディスクを稼働中の仮想マシンにマウントして、ファイルベースでリストアを行う機能が搭載されていました。

ただ、今までの機能ではコマンドでの操作が必要であり消してシンプルな操作でファイルリストアができるとは言い難い状況でした。

そこで、AOS5.0からリリースされた機能が、「Self Service Restore (通称SRR）」です。

この機能の目的は、

1. Nutanixで取得したスナップショットから任意のファイルをリストアできる
2. Nutanixの管理者のオペレーションを介さず、稼働している仮想マシンの管理者の操作だけでファイルのリストアが可能

という点です。

1点目は、そもそも課題であった問題を解決するものであり、容易に想像できますが2点目は、どういう意味？と思われる方もいるかもしれません。

これは、Nutanixを仮想化基盤として運用し、部門別のファイルサーバーなどはその部門サーバーの管理者が運用するケースを想定しています。

バックアップは、仮想化基盤管理者が一括で行うケースが多く、一方でファイルサーバーの利用者が、ファイルを誤って上書き・削除したなどでサルベージを求めて依頼をするのは、部門ファイルサーバー管理者になります。依頼を受けたファイルサーバー管理者は、仮想化基盤で一括で取得されたバックアップデーターを直接操作することができないため、仮想化基盤管理者にファイルのリストアを依頼することになります。

この場合、１つのファイルをリストアするために複数人がかかわることになります。ただこのようなファイルリストアオペレーションは、日常茶飯事であり情報システムを利用する社員が多い会社の場合、この作業だけでシステム管理者の1日が終わってしまうこともあるかもしれません。

ユーザーから見ると、お願いしても複数人を介すので非常に面倒

仮想化基盤管理者から見ると、たくさんの部門の人からこのような依頼が来ると、たいしたことが買い作業ではあるが、手間が増え非常に面倒。ただ、部門管理者に基盤全体のバックアップリポジトリを開放すると、その部門に関係のないバックアップデーター等を閲覧されるとセキュリティ的な問題が発生するなどの課題があり、どうしても基盤管理者の仕事として受けざるを得ないというジレンマがありました。

このような問題を根本解決するというのが、SSRなのです。

次回の項で具体的にSSRの利用方法を見ていきましょう。

CVMのVLANを変更する方法

Nutanixは初期出荷時からCVM(Controller VM)がデプロイされた形で出荷されるため、導入作業において、CVMのデプロイ作業等を行う必要は特にありません。

Nutanix的には、CVMは特別な存在の仮想マシンとして取り扱われ、PRISMの画面で、仮想マシン一覧を表示してもCVMは、デフォルトでは表示されません。

また、このCVMを意図的にシャットダウンをすることもできません。

このCVMは、デフォルトVLAN（つまりUntag）で設定されています。
CVMの通信を意図的に別のVLANに変更した場合、vSphereの場合は、ポートグループを変更することだけで対応可能ですが、AHVの場合はコマンドを使っての対応となります。

今回は、その手法をご紹介します。
尚、この作業は各AHVホストで作業を行います。Nutanixのノードが10台あるのであれば、10台共に行う必要がある作業となりますのでご注意ください。

1.まず、TeraTerm等でSSHにてAHVホストにログインします。

2.AHVから、CVMに「192.168.5.254」を使ってログインします。
（192.168.5.254は、CVMの内部通信側のIPアドレスとなります。そのためどのAHVホストから接続してもCVMのIPアドレスは192.168.5.254で接続可能です）
ログインは、nutanixユーザーでログインしましょう。

#ssh nutanix@192.168.5.254

3.VLAN変更コマンドを実行します。（この場合、VLAN10に変更）

$ change_cvm_vlan 10

最後に「CVM external NIC successfully updated.」というメッセージが出たら終わりです。「exit」コマンドでCVMへの接続を終了します。
また、AHVの接続も「exit」コマンドで終了します。

CVMのVLAN変更は特に何も難しいものではありません。

NICのMacアドレスを変えずにVLANを変更する方法

AHVにて、仮想マシンのVLANを変更したいとき、vSphereであれば、ポートグループの変更で完了ですが、AHVの場合、ちょっと一癖あります。
それは、PRISM上でNICのVLANの割り当てを変更するためには、NICの削除し、その後追加というアクションになり、NICのMACアドレスが変わってしまうということです。

サーバー環境であればあまりないかと思いますが、MACアドレスでネットワーク認証やアクセスできるものを制限している場合、VLANを変えるたびに（そんなにVLANをころころ変更することも無いと思いますが）MACアドレスが変わるのもあまり好ましいことでもありません。

さて、MACアドレスを変えずに、VLANを変更する方法をご紹介します。

まず、SSHを利用して、CVM（cluste vip）に接続を行います。

まず、既存の仮想マシンのMACアドレスを確認します。

acli vm.nic_list "仮想マシン名"

すると、仮想マシンのMACアドレスと属しているVLANが表示されます。

例）仮想マシンが「Windows Server 2016」の場合
コマンド：acli vm.nic_list "Windows Server 2016"
結果：

次に、VLANを変更します。

acli vm.nic_update 仮想マシン名 MACアドレス network=ネットワーク名

例）上記の仮想マシンの「52:54:00:a8:89:46」をVLAN20に変更する
コマンド：acli vm.nic_update "Windows Server 2016" 52:54:00:a8:89:46 network=VLAN20


結果：

尚、この作業は仮想マシンが停止していないとできない作業です。
仮想マシンがPowerOn中に作業すると

NicUpdate: pending
NicUpdate: kInvalidState: Cannot complete request in state kOn

と表示され実行に失敗します。

ちょっと面倒なのですが、AOS4.7では、この手法でMACアドレスを変えずにVLAN変更できます。

Nutanixにおける電源ケーブルについて

Nutanix純正は、200V電源を利用することが基本前提となります。
200Vというと、ブレードサーバーで一般的であった、L6-30やL6-20などの電源コンセントと、サーバー側は、C19といったコネクターを想像されるケースが多いかと思います。


(参考）コンセント形状　amazon.comより

しかし、Nutanixでは、L6-30でもC-19のコネクターでもないものが付属してきます。
Nutanixを購入した場合に付属する電源ケーブルは「C13」「C14」のケーブルとなります。

（参考）C13-C14ケーブル

このケーブルを、PCとディスプレイの電源接続ケーブルとか、電源延長ケーブルと認識されているケースもありますが、これは歴とした電源ケーブルになります。
そもそも、現在販売されているPCやサーバーのほとんどは200Vに対応しており、上記のようにC13-C14をつかって200V電源で接続することは可能です。

では、このケーブルをどのように電源コンセントに接続するのでしょうか？
答えは、PDUを利用するということです。

PDUとは、単純に行ってしまえばOAタップみたいなものです。
200Vの電源形状を様々な形状に変換して電源を提供してくれます。

PDUは、UPSメーカーなどから発売されていますのでそちらを手配し、配電盤から提供された電源コネクタ（主にL6-30等）をPDUを接続し（状況によってはUPS経由）PDUとNutanixを接続することになります。

（参考）PDUの例 シュナイダー AP791A

AHVで、既存の仮想マシンをテンプレートとして利用する方法

この記事は、古い記事となっております。2025年5月現在、Prism Centralを使ったテンプレート機能が利用できますので、そちらの機能の利用もご検討ください。なお、こちらで記載の手法は、現在でも利用可能です

vSphereには、作成した仮想マシンをテンプレートとして保存し、都度その点プレートを元に仮想マシンを簡単にコピー・カスタマイズして展開をする機能を持っています。
この機能は、都度仮想マシンが必要になった際に、OSのインストールやアップデート作業など事前作業をスキップすることができるため大変有効な機能だと思います。

では、AHVを利用した場合、これに相当する機能はあるかという疑問がわいてきます。

この記事を書いている環境は、「AOS4.7.2」ですので、今後新しいバージョンではわかりませんが、現段階では、vSphereの仮想マシンテンプレートに相当する機能は存在しないようです。

ただし、仮想マシンのクローンだけでよければ、仮想マシンのコピーはもちろん可能です。
（残念ながら、コピー時にsysprepをかけるとか、ホスト名を変更するなどはできません）

しかし、クローンの元となるゴールドイメージも通常運用する仮想マシンの一覧に上がってくると、謝ってゴールドイメージの仮想マシンの電源を入れて、不要なオペレーションをしてしまうことや、そもそもゴールドイメージの仮想マシンを誤って消してしまうこともあり得るかもしれません。

そういったオペレーションを防ぎ、ゴールドイメージから仮想マシンを展開する機能として、「Image Service」という機能が、AHV版のNutanixには搭載されています。

これは、以前に紹介したHyper-Vからの移行の際にも利用しました。
この機能は、元々ゴールドイメージを管理するためのツールです。
しかし、このImage Serviceは、GUIからですと、既存でAHV上に存在する仮想マシンを、Image Serviceに登録することができません。

ただ、コマンドを利用すればImage Serviceに作成した仮想マシンの仮想ディスクをゴールドイメージとして登録することができます。
今回はその方法をご紹介したいと思います。

まずは、CVMに接続して、テンプレートにしたい仮想マシンのUUIDを調べます。
仮想マシン名称に半角スペース等が入っている場合は、「"」を前後につけてコマンドを実行しましょう。

acli vm.get "仮想マシン名"

すると結果として以下のような結果が出てきます。

VM-Windows Server 2016 {
  config {
    annotation: ""
    disk_list {
      addr {
        bus: "ide"
        index: 0
      }
      cdrom: True
      container_id: 289271
      container_uuid: "dfda6b0f-5a5a-404b-a3dd-b4ff588fbdfd"
      source_nfs_path: "/Container/.ngt/89b1e252-2b06-4ad0-b59b-a4339cd62784/nutanix_guest_tools.iso"
      vmdisk_size: 91115520
      vmdisk_uuid: "5c199427-4978-4983-a889-ee5d8d028415"
    }
    disk_list {
      addr {
        bus: "scsi"
        index: 0
      }
      container_id: 289271
      container_uuid: "dfda6b0f-5a5a-404b-a3dd-b4ff588fbdfd"
      vmdisk_size: 64424509440
      vmdisk_uuid: "cb97b701-5c23-495e-9417-b39530dfe2c3"
    }
    max_hotplug_memory_mb: 262144
    memory_mb: 3072
    name: "Windows Server 2016"
    nic_list {
      mac_addr: "52:54:00:0f:07:19"
      network_name: "AHV Network"
      network_uuid: "409aa584-f180-4937-89e2-b56d68c89865"
    }
    num_cores_per_vcpu: 1
    num_vcpus: 2
  }
  logical_timestamp: 12
  state: "kOff"
  uuid: "89b1e252-2b06-4ad0-b59b-a4339cd62784"
}

この中の仮想ディスクにあたり箇所の「vmdisk_uuid」を選択します。
上位にある「vmdisk_uuid: "5c199427-4978-4983-a889-ee5d8d028415"」は、「cdrom:True」と記載がありますので、こちらではなく「vmdisk_uuid: "cb97b701-5c23-495e-9417-b39530dfe2c3"」になります。間違えないように注意が必要です。

あとは、この仮想ディスクのUUIDを元にイメージサービスに登録をするだけです。

acli image.create "イメージ名" clone_from_vmdisk=ゴールドイメージの仮想ディスクUUID  image_type=kDiskImage

今回は、イメージ名を「Windows Server 2016 Template」とし、上記の仮想マシン情報から取得した仮想ディスクを元に作成したいと思いますので、以下のコマンドとなります。

acli image.create "Windows Server 2016 Template" clone_from_vmdisk=cb97b701-5c23-495e-9417-b39530dfe2c3 image_type=kDiskImage

おそらく、登録はほぼ一瞬で終わると思います。
これで、Image Serviceを見てみると登録されていることがわかります。

では、テンプレートから仮想マシンを作成する際の手法も簡単に押さえておきましょう。
まずは、普通の仮想マシンを作成し、Diskを追加します。

仮想ディスクを追加する際に、Operationを「CLONE FORM IMAGE SERVICE」を選択すると、先ほど作成したテンプレートが出てきますので、これを選択し、必要な容量を設定した上でディスクをAddしてください。

これで、後は普通通りに仮想マシンを作成すれば終わりです。
ちょっと一手間ありますが、そんなに難しい手法ではありません。

今後新しいバージョンでおそらくGUIからの操作ができるようになる気がしますが、それまでの間は、この手法でゴールドイメージの管理が可能です。

CVMの地域設定変更方法

前回の投稿で、ゲストVMがWindowsの際に時刻のずれに対応する方法をお伝えしました。
これは、AHV側のTimeZoneが「PST」になっているのがその要因であるという話しもお伝えしました。

さてこの課題は、仮想マシンとして提供されている「CVM」(Controller VM）にも当てはまります。
CVMは、Linuxベースですのでソフトウェアクロックとハードウェアクロックの概念はありますが、そのTimeZone設定はやはり「PST」で設定されています。

CMV側で時刻に関する作業というのはあまりないかもしれませんが、やはりわかりやすい時間にしておくことは、問題解決において有効な1つの策であると思います。

さて、CVMに対する時刻のずれですが、こちらはタイムゾーンの変更で行います。

CVMにSSHでログイン後

ncli cluster set-timezone timezone=Asia/Tokyo

入れるだけです。 わざわざ1つずつのCVMにログインし、cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime　なんてことはする必要はありません。
こちらは、AHVでもvSphere(ESXi)でも同様の事項ですので、押さえておきたい事項の一つです。

AHVにおけるWindows仮想マシンの時間設定の注意点

AHVの上に、Windowsの仮想マシンを作成し稼働させると、時間がなんか変だなと思うことがあるかと思います。

vSphereを使っている場合ですと、VMware Toolsをインストールすることで、時刻が正しい時間に修正されますが、AHVの場合、NGT(Nutanix Guest Tools)のインストールをしても時刻は特にかわりがありません。

これは、AHVのタイムゾーン設定に要因があります。

AHVのタイムゾーンは「PST」（太平洋標準時）に設定されています。
その時差は、UTCよりも8時間遅い（夏時間は7時間）ようですので、日本との時差は、17時間ということになります。

（参考）wikipedia 太平洋標準時


そもそもWindowsは、UNIX系OSと違いハードウェアクロックとソフトウェアクロックという概念を持っていないため、ハードウェア側のクロックにOS側が依存することによりこのような時差問題に気づきやすいことで、このような事象に気がつくケースもあるかもしれません。

vSphereの場合なども,昔はハイパーバイザーの時間にゲストVMの時間が合わせる形が一般的でしたが、最近はハイパーバイザーとゲストVMは分離し、時刻同期はゲスト側で行うことが一般的となっています。

しかしAHVの場合、このPSTというタイムゾーン設定のためか、上物のゲストOSで時刻設定を行ってもパワーオフをしてまたパワーオンすると時刻がずれる等の症状が見受けられます。

では、ハイパーバイザー側のTimeZoneを変更しようと思うかと思いますが、サポートの面等々を考えるとこれはあまり得策ではありません。

この対処法として、ゲストOSであるWindows側のレジストリを操作することでこの問題を解決することができます。


場所は、

「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation」

になります。

ここに以下のDWORD（32ビット）を作成します。
（日本語読みは、リアルタイム　イズ　ユニバーサルです。）

　DWORD(32ビット)：　RealTimeIsUniversal

値には「１」をセットします。

　RealTimeIsUniversal　値：1

(参考）

この設定を施した上で、ゲストOSを再起動をしましょう。
また、ゲストOSのNTP設定も忘れずに行ってください。
（Windows Server 2008以降は、おそらく自動でNTP設定がなされているはずですし、ドメイン参加時は、ドメインコントローラーと時刻同期されるはずですが、念のために確認をしておきましょう）

HyperVからAHVへの仮想マシン移行その３ VHDX仮想ディスクでの移行方法

前回の投稿では、VHDファイルで作成されたHyper-V仮想マシンの移行方法をご紹介しました。
非常に手軽に移行できたのがわかります。
では、Windows 2012から採用されたVHDXの移行方法についても見ていきたいと思います。

まずは、今回の移行環境です。

AOS	4.7.2
AHV	20160217.2
Hyper-V	2012R2
ゲストOS	2012R2
世代	第1世代

まずは、VHDの移行の時と同様、VM Mobilityをインストールします。
VM Mobilityについては、以下を参考にしてください。

（参考）
http://infraapp.blogspot.jp/2016/12/hypervahv-vhd.html

ドライバーを含めインストールが行われます。
一部ドライバーインストールで確認画面が表示される場合がありますので、その際は許可してドライバーをインストールします。

インストールが完了したら仮想マシンの準備はこれで終わりです。

さて、ここから同じくImage ServiceにPutすればOKかというと、実はそうではありません。
VHDXの場合は、Nutanixのコンテナに直接ファイルを配置し、コマンドを使ってディスクイメージを変換する必要があります。
まずは、NFSでNutanixのストレージをマウントし、VHDXファイルを配置するところから始めましょう。

Windows Server 2012 R2の場合、サーバーマネージャーから「管理」メニューの「役割と機能の追加」を選択します。

まずは、ウィザードを進めます。

次に、「役割ベースまたは機能ベースのインストール」を選択します。

インストールするサーバーを選択します。

役割は追加せずに次へをクリックします。

NFSクライアントにチェックをいれ次へをクリックします。

タスクを確認し、インストールをクリックします。

インストールタスクが走りますので、インストールが完了するまで待ちます。

インストールが完了したら、「閉じる」をクリックします。

ここから、このWindows Server 2012 R2のOSから、Nutanixのコンテナをマウントします。
その前に、マウントしたいコンテナにホワイトリスト設定をしておく必要があります。

Nutanix側のPRISMにログインします。
ログイン後、メニューからStorageの画面に行きます。
そこから、これからマウントしたコンテナを選択し、Updateボタンをクリックします。

コンテナの設定画面が出ますので、「Advanced Setting」を選択します。

ホワイトリスト設定の画面が出てきますので、ここでマウントしたいマシンのIPアドレスを入れてマウント可能なアドレスとして登録をしておきます。入力は「192.168.0.0/255.255.255.0」といった形式での入力となりますので、CIDR形式と違うことに注意が必要です。

これで、Windowsからのマウントができる準備ができました。
Windows Server 2012 R2側で、コマントプロンプトを立ち上げて、Nutanixのストレージコンテナをマウントしてみましょう。

Windowsでマウントする場合は、以下のコマンドを利用します。

mount \\Nutanixの任意のCVM\コンテナ名 *

正常にマウントが成功すると「コマンドは正常に終了しました」と表示されます。

マイコンピューターから見てみると、ネットワークドライブとしてコンテナがマウントされていることがわかります。

このマウントしたNFSのドライブに、Hyper-Vで利用していた、VHDXファイルをコピーします。

このファイルコピーが終わったら、今度はAHVで読み込めるようにファイルを変換する必要があります。まずは、SSHで、CVMにログインします。

ここで登場するのが「qemu-img」コマンドです。

具体的には以下のコマンドを実行します。

qemu-img convert -f vhdx -O raw 元のVHDXファイル 変換後のファイル

となります。CVMから直接コンテナを見ることができませんので今回は、NFSを利用します。
CVMからコンテナをマウントする場合は、CVMがストレージサービスを提供しているため、127.0.0.1のアドレスを利用できます。

qemu-img convert -f vhdx -O raw nfs://127.0.0.1/container/Windows2012R2-V2.vhdx nfs://127.0.0.1/container/Windows2012R2-V2.raw

変換が終わったら、仮想マシンをPRISMから作成します。
VMメニューからCreate VMをクリックします。

仮想マシンのスペックを入力します。Hyper-Vの仮想マシン構成情報は引き継がれませんので手動で必要なスペックを構成します。

続けて、仮想ディスクをマウントする必要がありますので「Add new disk」をクリックします。

ここで仮想ディスクのマウント設定を行います。

ここで設定のポイントがいくつかあります。
まず、OPERATIONは、「CLONE FORM ADSF FILE」を選択することです。
コンテナを直接NFSでマウントし。、VHDXファイルの配置とqemu-imgコマンドで変換をしましたので、これはNutanixの管理配下にあるものではありません。
また、このファイルは直ファイルパスでの設定が必要になります。これが「PATH」の項になります。
PATHは、「/コンテナ名/ファイル名」となります。ファイルはかならず変換後の「raw」を選択します。
ファイル名をある程度入れると補完機能がありますので、自動的に候補が出てきますのでそこまで難しくないと思います。
また、ディスクサイズも手で入力する必要があります。
元のイメージよりも大きいサイズ（もしくは同じサイズ）で設定する必要があります。

上記の設定が終わったら、Addをクリックします。

仮想ディスクが追加されたのを確認し、適宜仮想NICを追加後、「Save」をクリックし、仮想マシンを保存します。

仮想マシンを保存したのち、実際に起動してみましょう
何事もなかったかのように仮想マシンが起動します。

VHDとの違いは、コマンドで仮想ディスクファイルの変換が必要となりますが、基本はそのひと手間だけです。

Hyper-VからAHVへの移行はそんなに難しいものではないかとが、理解できたかともいます。