Prism Centralの活用その7（ストレージコンテナのマイグレーション）

vSphere環境においては、Datastoreに配置した仮想マシンを別のDatastoreに配置変更する、Storage vMotionが存在します。

Nutanix+AHV環境においては、従来の3Tierストレージのように利用用途に応じてDatastoreを分ける運用は非効率なため、ストレージコンテナを複数作るケースは、そこまで多くなかったことから、実装としてもそこまで重要視されていないように思われました。

しかし、ストレージのポリシー違い（圧縮・重複排除やデータ冗長度）で複数ストレージコンテナを作成するケースはあり、運用ポリシーの変更で、仮想マシン（仮想ディスク）を別のストレージコンテナに移行したいケースは0ではありません。

そのため、仮想ディスクのストレージコンテナの移行については、AOS 5.19のアップデートで実装されたことを以前に紹介しました。

AOS 5.19アップデート（その2）AHV環境における仮想マシンのストレージコンテナ移動

この当時、acliコマンドでしか操作ができなかったのですが、現在では、Prism Centralを介すことで、既に作成された仮想マシンの仮想ディスクを別のストレージコンテナに移行することができます。

では、そのオペレーションをご紹介します。

まずは、Prism Centralの「Infrastructure」から「VMs」を開きます。

仮想ディスクのストレージコンテナを変更したい仮想マシンを選択し、「Update」をクリックします。

仮想マシンのvCPU等の変更画面が出ますので、特に変更の必要が無ければそのまま「Next」をクリックします。

続いて、Disksの画面を確認します。

ここでは、1つの仮想ディスクが「000.DEFAULT-MSG-CONTAINER」に配置されております。この仮想ディスクを鉛筆マークをクリックし変更を行います。

ここから、移行したいストレージコンテナを選択します。

選択後Updateをクリックします。

ただ、Update VMの表示は変更されません...。（多分バグだと思います）

選択後、あとはNextを数度クリックし、サマリーを確認します。

個々の表示も、移行前の仮想ディスクの表示になります。（おそらく現在の配置されているストレージコンテナが表示される仕様なのでしょう...）気にせずSaveをクリックします。

すると、Updateが行われ、タスクには、Migrate vDiskのタスクが作成され、仮想ディスクの移行が行われます。

タスクが成功すると、仮想マシンのUpdateから情報を見るとストレージコンテナが今回変更した「WORKING-CONTAINER」に変更されていることがわかります。

未だに、コマンド含めVolume Groupのストレージコンテナ移行は、サポートされていませんが、GUIで操作ができるようになったことで、少しオペレーションのハードルは下がったかと思います。（UI表示が所々おかしいですが）

AOS 5.19アップデート（その2）AHV環境における仮想マシンのストレージコンテナ移動

AOS 5.19で搭載された機能の1つで、AHV環境における仮想ディスクのストレージコンテナ間移動機能があります。vSphereにおいては、vSphere Standard以上で、Storage vMotionという機能を利用することで、仮想マシンを稼動したままDatastore間の移動ができます。

Nutanix + vSphere ESXiの組み合わせにおいても、Storage vMotionは利用可能です。一方で、Nutanix ＋ AHV環境においては、仮想マシンを稼動したままストレージコンテナ間を移動する機能は、ありませんでした。AHV環境の場合、ストレージコンテナ間を仮想マシンが移動するユースケースとしては、元々RF2で稼動してた仮想マシンを、よりミッションクリティカルなRF3で稼動しているストレージコンテナに再配置したいなどのストレージポリシーが異なるストレージコンテナに仮想マシンを再配置したい場合に利用するぐらいで、ストレージのリプレース等で利用することはありませんので、そこまで必須という機能では無かったため、今までは仮想マシンを停止してImage Serviceを経由して仮想ディスクを複製するという形で対応をしていました。ただ、Image Serviceでの登録は、様々なパラメーターを必要とするため、簡単に移動という訳にはいかず、一手間かかる物でした。

今後は、Image Serviceを利用せずに仮想ディスクの移動が可能となります。

では、その手順をご紹介いたします。

まずはじめに、この機能はまだGUIでは搭載されておらず、acliを利用して行う必要があります。

コマンドは簡単です。「vm.update_container VM名 container=移行先のコンテナ wait=false」で移動できます。パラメーターとして「disk_addr_list=」を付けるとその仮想マシンに接続されている複数の仮想ディスクのUUIDを指定した仮想ディスクだけを移動対象にすることも可能です。この場合カンマ切りで複数の仮想ディスクを指定することも可能です。今回は「vDiskMove-VM」という仮想マシンを、「SECONDE-CONTAINER」というストレージコンテナに移動したいと思います。

vm.update_container vDiskMove-VM container=SECOND-CONTAINER wait=false

これだけで完了です。コマンドのみとはいえ、そこまでハードルの高いもではありません。

移行作業が開始されるとタスクの進捗を確認できます。

なお、仮想ディスクを移動する際には以下の注意点があります。

• 移動中は仮想マシンのクローン及びスナップショットの取得が出来ません
• 仮想ディスク移動中は、仮想ディスクコピーを行うため一時的にストレージの利用料が増えます。移動が完了すると使用容量は元に戻ります
• ProtectionDomainで保護されている仮想マシンは、移動できません。あらかじめProtection Domainの保護対象から除外する必要があります。
• Volume Groupで、仮想ディスクが直接SCSIでアタッチされている環境の場合、仮想マシンで利用しているVolume Group以外の仮想ディスクのvmdisk_uuidを指定する必要があります。

上記の事柄から、Volume Groupのストレージコンテナ移動は現状対応していません。従来通りImage Serviceを利用して移動する必要があります。

DataProtectionの除外設定は、Entitiesから移動したい仮想マシンを「Unprotect」で保護対象から外すだけで良いです。Local SnapshotsやSchedulesを削除する必要はありません。仮想ディスクを移動後に再びEntitiesに仮想マシンを再登録することで再保護が可能です。

ただし注意点としては、仮想ディスクを移動する前に取得したスナップショットは、移動前のストレージコンテナに保存されたままとなります。そのため、移動する前のスナップショットでリストアすると、スナップショットを取得した時点でのストレージコンテナにリストアされます。これは、Data Protectionで取得したスナップショットは仮想マシンがその時点で存在するストレージコンテナに保持されるためです。

また、もう一つの注意点は、DataProtectionのスナップショットでは無く、AHVの仮想マシンに対して取得できる「VM Snapshots」のスナップショットです。VM Snapshotsは保持したまま仮想ディスクの移動は可能です。しかしこのスナップショットも取得した時点でのストレージコンテナに保存されています。そのため、仮想マシンを別のストレージコンテナに移動後、移動前に取得したスナップショットをリストアした場合、スナップショットを取得した時点のストレージコンテナに戻ってしまいます。

今回は新たに追加された仮想マシンのストレージコンテナ移動機能について紹介しました。スナップショットの取扱いの注意点やVolume Groupがまだ未対応、acliでのみ操作可能など、まだ荒削りところはありますが、今までのImage Serviceでの操作に比べると大変楽に作業できると思います。