💽
手元のHyper-V上のWindows Server 2022(Gen2)のVHDをAzureに持ち込んでカスタムイメージとして利用する
モチベ
- 手元のHyper-Vで稼働しているWindows ServerをAzureに持ち込んで利用したいシナリオの検証がしたい
- 単に移行ということを考慮するのであればAzure Migrateを利用するのがシンプルかもしれないが、クライアントOS非対応のため「VHDを持ち込む」パターンでのAzure移行を試してみる
※なお、Sysprepは一旦無しで実施してます
Hyper-V上にWindows Server 2022のVMを作成
- このあたりに.isoが置いてあるのでそのファイルを参照する形でOSのインストールを実施
インストール手順
- Windows11上でHyper-Vを有効化
- Hyper-V上で[新規]>[仮想マシン]からVM作成
- ※今回は第2世代を利用したいので、[第2世代]を選択する(後のハマりポイント)
- VM側でインターネット利用
- vhdxの保存場所
- isoファイルの指定
- 具体的な作成手順はこちらも参考に(クイック作成)
Hyper-V VM上で必要な変更を実施
- ここではGoogle Chrome入れたり、Desktopにテキストファイルを配置
VHDのアップロードの準備
ゲストOS上での作業
- こちらのDocsにある手順をポチポチやっていく
- https://learn.microsoft.com/ja-jp/azure/virtual-machines/windows/prepare-for-upload-vhd-image#complete-the-recommended-configurations
- この作業の中で、ゲストOS側のRDP許可の設定(Marketplace上のVMでは既定で許可)なども行っていく
- また、Azure Portalでの管理のために仮想マシンエージェントも入れておく事が推奨
- Windows Updateも当てる
Hyper-Vコンソール上での作業
- [ディスクの編集]からVHDを作っていく(Azureに持ち込めるのは固定容量のVHDのみ)
設定項目(スクショ付き)
- 構成したHyper-V上のVMのVHDXを選択
- [変換]からVHDXをもとに新しいVHDを作成
- [VHD]を選択
- [容量固定]を選択
- 新規VHDの名前を付けて保存
- 編集の完了を待つ(少々時間がかかる)
- VHDの生成を確認してアップロードの手順へ移る
VHDのアップロード
ローカルでの作業
- 手順はこのDocsに載っている
- https://learn.microsoft.com/ja-jp/azure/virtual-machines/windows/disks-upload-vhd-to-managed-disk-powershell#manual-upload
- 今回は、手動アップロードのパートを実施
- Connect-AzAccount
- ローカルのPowerShellからAzureに空のマネージドディスクを作成
- マネージドディスクのSASを発行
- SAS経由でVHDをマネージドディスクに流し込み
- SASを失効
- VM作成
- Docsの手順をこなしていく
コラム:何も考えずにコマンドをコピペした場合の悲劇と解決
- Docsの一連の処理を終えるとディスクが作成されるので、そのディスクからVM作成
- デフォルト値で作成
- 「ん?Gen1?まぁいいか、見なかったことにしよう…」
- RDPアクセス
- 見たくないやつが出る
- とりあえずツイートして悩む
- 「なるほどわからん」
- ブート診断を見てみると、
Boot failure
が出ている(※何度かチャレンジした後のVMなのでVM名が異なります) - 「起動できてないってことは、起動オプションのズレか?ちゃんとGen2指定できるところどこかに無いか?」
- 「New-AzDiskConfigや...!」
コラム:AzCopyについての補足
- AzCopy自体はアプリケーションなのでインストールするものではない
- 下記リンクからダウンロードして解凍しておく
- https://learn.microsoft.com/ja-jp/azure/storage/common/storage-use-azcopy-v10#download-azcopy
- コマンド自体はこんな感じになるはず
```powershell
ps> .\azcopy.exe copy "C:\ProgramData\Microsoft\Windows\Virtual Hard Disks\vhd-export.vhd" $diskSas.AccessSAS --blob-type PageBlob
```
- こんな感じで終わる
```
100.0 %, 1 Done, 0 Failed, 0 Pending, 0 Skipped, 1 Total,
Job b052fe70-fe57-8445-75fa-0bd8795e9386 summary
Elapsed Time (Minutes): 5.3346
Number of File Transfers: 1
Number of Folder Property Transfers: 0
Number of Symlink Transfers: 0
Total Number of Transfers: 1
Number of File Transfers Completed: 1
Number of Folder Transfers Completed: 0
Number of File Transfers Failed: 0
Number of Folder Transfers Failed: 0
Number of File Transfers Skipped: 0
Number of Folder Transfers Skipped: 0
TotalBytesTransferred: 136365212160
Final Job Status: Completed
```
Azure Portal上での作業
- 作業を終えてAzure Portalへアクセスしてみると、ディスクが生成されている
- VMを作成(イメージの部分がきちんと
Gen2
になっている) - デプロイ完了を待ち、運命のRDP
- 「RDPいけた...!(感動)」
- インストールしたGoogle Chromeや作成したテキストファイルも残っている
コラム:ブート診断ちゃんと見よう
-
RDPできるか否かという観点だけで評価しようとしていたため、原因の特定に時間がかかった
-
最初VMエージェントも入れていなかったので、ブート診断含むAzure Portalの機能がどこまで使えるのかよくわかっていなかったというのもある
-
Gen1(中身Gen2)のイメージから作成したVM
Boot failure
-
Gen2のイメージから作成したVM
- 起動中
おわり
- Gen2にしてもだめだったらWindows Server 2019でやってみるとか、Hyper-V側をGen1にするとかいろいろやらねばだったので解決できて何より
- 今回の結果からするとDiskConfigとHyper-Vの世代が合っていればよさそうなので、Gen1でやれば何も引っかかることなく出来ていた節はある
- ただトラシューを乗り越えて成長した感はあるのでヨシ
- クラウドネイティブ世代なのでHyper-Vに抵抗感なくなったのもちょっと嬉しい
- 次回はこのカスタムイメージから作成したVMをどう管理するか、というテーマで検証していく所存
zukako
GitHubで編集を提案
Discussion