2016年12月13日火曜日

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

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からの操作ができるようになる気がしますが、それまでの間は、この手法でゴールドイメージの管理が可能です。





2016年12月12日月曜日

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

値には「1」をセットします。
 RealTimeIsUniversal 値:1

(参考)


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







2016年12月11日日曜日

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

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

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


AOS4.7.2
AHV20160217.2
Hyper-V2012R2
ゲストOS2012R2
世代第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への移行はそんなに難しいものではないかとが、理解できたかともいます。





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

前回の投稿で、Hyoer-Vの仮想ディスク形式にVHDとVHDXの2種類があるというお話をしました。
では、実際に2008R2のHyper-V環境にある仮想マシンを、AHVに移行したいと思います。

まず今回の環境ですが、


AOS4.7.2
AHV20160217.2
Hyper-V2008R2
ゲストOS2008R2
世代第1世代

となります。

では、実際の手順を見ていきましょう。

まず、Hyper-Vで稼働している仮想マシン上で、行う作業が1つあります。
それは、Nutanix VM Mobilityを、仮想マシンにインストールしておく必要があります。

VM Mobilityは、Nutanixのサポートページからダウンロードすることができます。





ファイルは、MSIになっていますゲストOSで直接ダウンロードするか、ファイルサーバー等からアクセスする形でも構いません。
では早速インストールと行きたいところなのですが、実はその前に確認しておくことがあります。これは、SHA2の対応が必要で、WindowsのKB3033929が適用されている必要があります。

(参考)KB3033929
https://technet.microsoft.com/ja-jp/library/security/3033929.aspx?f=255&MSPPError=-2147217396

さて、パッチ3033929を適用後、改めてVM Mobiltyをインストールしましょう。


インストール自身は1~2分程度です。

途中でドライバーのインストールを聞かれますので、インストールをクリックします。






これだけの手順でインストールは完了です。


インストール完了後、特に再起動は必要ありません。
これから仮想マシンを移行しますので、この仮想マシンをシャットダウンしておきましょう。


では、Nutanix側でPRISMにログインし、Image Confugurationを開きます。


VHDファイルをアップロードしますので、Upload Imageを選択します。

アップロードに際して管理情報を入力します。
NAMEは、管理名を、ANNOTATIONは、説明事項になりますので入力が必要ない場合は空白でも構いません。
重要なのは、IMAGE TYPEです。ISOとDISKと選択肢がありますが、今回はVHDになりますので、「DISK」を選択する必要があります。
CONTAINERは、Nutanixで作成したストレージコンテナでVHDをどのコンテナに投入するかを選択します。
最後に、IMAGE SOURCEで、Upload a fileを選択し、今回の仮想マシンのVHDファイルを選択します。



VHDファイルがアップロードされ終わるまで待ちます。

アップロードが完了しました。しかし、画面上部のタスクを見ると、なにやら別のタスクが走っていることがわかります。


詳細を見てみると、Image Updateという処理が走っています。

これは、アップロードしたVHDファイルを、Nutanix側で扱うオブジェクトとして変換してくれています。同時にAHVで利用可能な仮想ディスクにしてくれます。

このタスクが完了したら、あとは仮想マシンを作成し、この仮想ディスクを割り当てるだけです。

メニューのVMから、Create VMをクリックします。


通常通り仮想マシンを作成します。仮想マシン構成情報は、Hyper-Vから移行されませんので必要に応じて、CPUやメモリーの割り当てを行う必要があります。

次に、ディスクを選択します。まずは、「Add new disk」をクリックします。

TYPEは、DISKを選択します。
OPERATIOnですが、今回はImage Serviceを利用してVHDをアップロードしましたので、「CLONE FROM IMAGE SERVICE」を選択します。
すると自動的に、Image Serviceに入っているものが出てきますので、該当するものを選択します。


BUS TYPEは、必要に応じてですが、今回はVM Mobilityをあらかじめインストールしておきましたので、SCSIドライバーもOS内にあらかじめ入っておりますので、SCSIを選択しましょう。
すべてのパラメーター入力が完了したら、Addをクリックします。

仮想ディスクが追加されたことを確認し、あとはAdd new NICで必要に応じてNICを追加し、SAVEをクリックし、仮想マシンを保存します。


作成した仮想マシンを実際にパワーオンして、Lunch Consoleで、画面を見てみましょう。


何事もなかったかのように仮想マシンが起動しました。
ハイパーバイザーが稼働するホストが変わったことで、一部再起動が発生する事項が出ていることがわかりますが、デバイスが何ら問題なく再認識されていることがわかります。
特にドライバーの場所参照場所指定などの画面が出てくることはありません。

Hyper-Vからの仮想マシン移行は、実はこんなに簡単に可能です。



HyperVからAHVへの仮想マシン移行その1

AHVの魅力は、Nutanixとの相性の良さと無償で高度なハイパーバイザー機能を提供してくれるところだと思います。
実際にNutanixを利用する際には、AHVのメリットを生かすために、現状他のハイパーバイザーで稼働していた仮想マシンをAHVへ移行することを考える必要があります。

vSphereからの移行の場合以前に紹介した、クロスハイパーバイザー機能を活用するなどして簡単に移行することが可能です。
しかし、"無償"というキーワードからの移行で考えると、Hyper-Vからの移行を検討される場合もあるかと思います。
今回は、Hyper-VからAHVへの移行方法をご紹介したいと思います。

まず、Hyper-Vの種類から先におさらいをしておきたいと思います。

Hyper-Vは、Windows Server 2008から搭載されたハイパーバイザー機能です。
その後、Windows8からは、クライアントOSにもHyper-Vが搭載されています。
大きくわけると、仮想マシンの世代として第1世代と第2世代という世代設定が2つあります。第2世代は、2012R2から搭載された機能で、BIOSではなくEFIになっているなどの、新しいアーキテクチャーが積極的に取り込まれているのが特徴です。

あと、世代に関係なくもう1つ注意する点は、仮想ディスクの形式です。
VHD形式とVHDX形式があり、Windows Server 2012より搭載されたのが、VHDX形式です。
64TBまでの容量サポートをされていることから、Windows Server 2012 R2では、ウィザードで仮想マシンを作成すると、自動的にVHDXが選択されます。
Windows Server 2008 R2でのHyper-V環境であれば、VHD形式しか選択できませんので、自動的にVHDとなります。

この仮想マシン世代と、仮想ディスクの形式に注意をしながら、AHVへの仮想マシン変換を行っていきたいと思います。

2016年12月4日日曜日

Nutanixのクロスハイパーバイザーを試してみるその③ 仮想マシンのレプリケーションとAHVでのリストア

この項では具体的に仮想マシンのレプリケーションを行う設定とリストアの手順を確認したいと思います。

まず、メインサイトのESXiで稼働している仮想マシンをDRサイトにレプリケーションする設定を行います。

PRISMのメニューから「Data Protection」選択し、右上の「Protection Domain」ボタンから、「Async DR」をクリックします。


バックアップ管理名称(ジョブ名)を入力し、Createボタンをクリックします。
今回は「Backup01」という名前で作成を行います。


左側の一覧からあがってくる仮想マシンを選択し、「Protect Selected Entities」をクリックし、右側のProtected Entitesの一覧に仮想マシン名が登録されていることを確認します。


続いて、レプリケーションのスケジュールを作成します。
右上の「New Schedule」をクリックします。


スケジュールは非常に柔軟に設定ができます。
数時間に1回という単位でのバックアップや数日に一回、毎週何曜日などの設定が可能です。
また、レプリケーション設定はまずローカルスナップショットデーターの転送となりますので、ローカル側のスナップショットの取得が必須となります。
ローカルとレプリケーション先で保持する世代数を変更するが可能ですので、要件に応じて世代数を設定しましょう。今回はローカルに5世代、レプリケーション先に3世代のスナップショットデーターのバックアップを保持する設定にしています。
スケジュール設定を行った後「Create Schedule」をクリックします。


設定したスケジュール情報が出ていることを確認し、「Close」をクリックします。


あとは、スケジュールで設定した時間まで待つばかりです。
待てない場合は、意図的にスナップショットを作成したいと思います。
作成したバックアップジョブを選択し、「Take Snapshot」をクリックします。
今回は取得したスナップショットをレプリケーション先に送りますので、"REMOTE SITE"の下に表示されるレプリケーション先(今回は、toDELL)を選択し、SAVEをクリックします。


スナップショットの作成が終わったら、いよいよDRサイト側のAHVのNutanixクラスターで仮想マシンを起動してみたいと思います。

AHV側のPRISMのメニューから「Data Protection」を選択し、ESXi側で作成したバックアップ上部が表示されていることを確認します。そのジョブを選択し、「Local Snapshot」のタブをクリックし、メインサイトのESXi側のスナップショットが一覧に上がっているのを確認します。
スナップショット一覧から、実際にAHV側で稼働させたい世代のスナップショットの右側にある「Restore」をクリックします。


リストア画面で、DRサイト側(AHV)で稼働させたい仮想マシンを選択し、How to Restoreで「Create new entities」選択します。
仮想マシン名に、AHVを頭につける形の設定をします。(こちらは任意です)
Exampleでリストア後の仮想マシン名が出るので、念のため確認をしておきます。
設定が完了したら、「OK」をクリックします。


リストア処理が開始されるとすると、PRISMの上部に「Snapshot restoration initiated successfully」と表示されます。スナップショットのリストアはストレージポインターの集合体を作るだけですので、一瞬で終わります。

PRISMのVMメニューから、Tableボタンを押し仮想マシン一覧を確認すると、先ほどリストアした仮想マシンが表示されているはずですので、その仮想マシンを選択し、「Power on」をクリックします。


Lunch Consoleをクリックすると、普通にOSが起動しているのがわかります。


OS起動後、デバイスの再検出等の画面も特に出ず、予期せぬシャットダウンの理由を求める画面が出てきます。仮想マシンは電源ONの状態でスナップショットを取得し、リカバリを行っているためこれは仕方がありません。適当な理由を選択し、OKをクリックします。


実はこれだけで、これ以降は何ら普通の仮想マシンと変わりなく利用することができます。
コマンド操作や変換操作などは一切不要です。

今回は、Nutanix的にはAHVではまだ非サポートなWindows Server 2016を利用しましたが、何ら問題なく動作しました。

投稿としては3回に分けての投稿となりましたが、これだけの一連の操作は、わずか12~3分で終了します。

DR環境だけでなく、vSphere上で稼働する仮想マシンをAHVに移行する時にもこの手法は可能です。