AzureのサービスにStorage MoverというPaaSが有ります。
ファイルサーバのデータ移行サービスで、オンプレミスのHyper-VかVM Ware上にStorage Moverのイメージを展開し、Azure Portal上でStorage Moverにオンプレミスのファイルサーバのデータを取得させ、Azure FilesやAzure Blob Storageにデータを同期する、というサービスです。
私はこのサービスでのお客様の本番環境でデータ移行の実績(10TiB)が既にあり、実際に使ってみた感想としては非常に簡便で優秀なデータ移行ツールです。
そのStorage Moverの検証環境を構築するのにOVAファイルをqcow2形式に変換する必要があったのでこの手順をまとめました。
本番環境での利用はやめましょう。
当たり前ですが技術的に可能なことと実際にやって良いこととは違います。
仮にこの方法でStorage Moverを構築したとしてもMicrosoftのサポート外になるので、データ移行で何か問題が発生しても誰も責任取ってくれません。
もちろん私も責任取れません。
検証環境にHyper-VやVM Wareが無い
はい。
私の検証環境がそうですね。
Ubuntu上のKVMで動作しています。
最悪VM Ware on KMV(KVM上でVM Wareを動作させる)やHyper-V on KVM(KVM上でHyper-Vを動作させる)という環境を実装すればなんとかなるのでしょうが、VM Ware on KVMは以前構築してうまく動かなかったため、別のアプローチを試してみました。
(※確か物理NICが1つしかないのでKVMの仮想NICとVM Wareの仮想Switchの設定ができなかったんじゃなかったかなと思います。)
Hyper-VやVM Wareは持っていないがKVMがあるので、KVM上でVM Wareのイメージを動かしたい
以前理由は忘れたのですが、VM WareのイメージをKVM上で動作させたいという事があり(恐らく何かの検証ですが詳細は忘れました)この時にVM WareのOVAファイルを展開してVMDXからqcow2に変換したことがあります。
またVMDXファイルをVHDファイルに変換したこともあり、VM Ware→Hyper-VやVM Ware→KVMという方向でのイメージの変換は可能なんだな
と朧気ながら記憶がありました。(確かKVMからVM Wareも可能なはずです。)
ざっくりした流れ
- OVAファイルからvmdkファイルを取り出す
- 取り出したvmdkファイルをqcow2に変換
これだけです。
VM Ware上で動作するStorage Moverのイメージを取得する
では早速Storage Moverのイメージを取得しましょう。
今回はたまたまStorage Moverを使っているだけなので、OVAファイルであればなんでも良いです。
こちらのURLからダウンロードしてください。
こういうサイトに飛ばされ、思わせぶりにSelect Languageという文言が有りますが、
安定の英語のみです。
[Download]ボタンをクリックすると、
[どれダウンロードしますか？]と聞かれるので、赤枠内のOVAファイルをダウンロードします。
KVMサーバにOVAファイルを移動する
SCPでさくっと移動ですね。
OVAファイルを展開する
OVAファイル、実はtarファイルなんですよね。
VM Ware界隈では有名なんですかね。
今回ファイル名がAzureStorageMover_3.3.760_amd64_VMware.ovaなので
tar -xvf AzureStorageMover_3.3.760_amd64_VMware.ova
で展開(というか解凍？どっちの表現が正しいのでしょうか？)できますね。
vmdkファイルを取り出す
はい。
上の赤下線で展開コマンド実行、ls -alコマンド実行して最後の行に居ますね。下の赤下線です。vmdkファイルが。
これでお目当てのvmdkファイルが無事取り出せました。
vmdkファイルをqcow2ファイルに変換
今回ファイル名がAzureStorageMover_3.3.760_amd64_VMware_disk0.vmdkなので、qcow2ファイルも同じ名前にするのであればコマンドは
qemu-img convert -O qcow AzureStorageMover_3.3.760_amd64_VMware_disk0.vmdk AzureStorageMover_3.3.760_amd64_VMware_disk0.qcow2
になります。
ちょっと長いですが、ファイル名の長さのせいですね。
ですが新しいファイル名考えるのが面倒なのと、変更後に元ファイルなんだっけ？とならないように同じファイル名にしました。
実行してみると
こんな感じですね。
上の赤下線でコマンド実行、下の赤下線にコマンド実行結果としてqcow2ファイルができています。
ホントにStorage Moverが起動するの？
ですよね。
動作確認しないと意味無いですよね？
vmkdファイルがqcow2に変換されたと思いきや、実はただのリネームかもしれませんしね。
以降の手順は普通のKVMの仮想マシン構築の手順と同じです。
作成したqcow2ファイルから仮想マシンを起動する
GUIで行きましょうか。
[仮想マシンマネージャー]を起動して[ファイル]から[新しい仮想マシン]を選択し[既存のディスクイメージをインポート]を選択して[進む]をクリックします。
[参照]をクリックして
先ほど作成したqcow2ファイルを選択し[ボリュームの選択]をクリックします。
OSの種類を聞いてくるので[Generic default]を選択し[進む]をクリックします。
[CPU]と[メモリ]を適当に入力し(たぶんあんまり小さすぎると起動しないかも)[進む]をクリックします。
[名前]も適当で良いですね。最後に[完了]をクリックします。
起動確認
はい。
この通りLinuxが起動していますね。
流石にメモリ4GiBは舐めすぎてましたね。
16GiBにしたらやっと起動しました。
どうやらOSはUbuntu22.04 LTSみたいですね。
ログイン
IDはadmin、初期パスワードもadminです。
はい。
無事ログインできましたね。
起動するまでに時間がかかり、更にStorage MoverのUbuntuが起動後、内部でContainerが起動するまで更に10分程度必要なので、まぁまぁ待ちます。
Containerが起動するまでにログインしてしまうと
No Container found with the prefix: container. If the agent was recently started, please wait until ten minutes after it was started before trying reconnect. Do you want to collect a support bundle for troubleshooting?(Y/n)
というエラーメッセージが出ます。
Containerも無事起動したら画像のように初期パスワード変更画面に進みます。
本格的な動作、データ移行などはまた機会があれば実施しようと思います。
まとめ
- OVAからvmdkファイルを取り出してqcow2ファイルに変換することは可能
- Azure Storage Moverは動作しそう(※ただしMicrosoft推奨構成ではないので自己責任)
- Azure Storage Moverの起動には時間がかかる(OSの起動以外に内部でコンテナの起動があるため)
本日はここまで。