一番の山場、それが「引っ越し」だった

前回まででProxmoxのインストールとストレージの準備までが終わった。ここからが本番――これまで物理PCとして使っていたWindows環境を、まるごと仮想マシンとしてProxmoxの中へ引っ越しさせる。いわゆる P2V（Physical to Virtual） だ。

結論から言うと、このシリーズで一番地雷を踏んだのがこの回だった。「バックアップを取ってインポートするだけでしょ？」と軽く見ていたら、容量切れ・ディスク破損・黒画面・ネット不通と、順番に問題が襲ってきた。ひとつずつ、実際に踏んだ順番で記録する。

手順① Disk2VHDで物理ディスクをまるごとVHDX化する

まず、動いている物理Windowsのシステムディスクを丸ごとイメージ化する。使ったのはMicrosoft（Sysinternals）の Disk2VHD。OSが起動したままでもスナップショットを取ってVHDX形式で書き出せるのが便利なところだ。

ポイントは2つ。

• 出力形式は VHDX を選ぶ（旧VHDより大容量・堅牢）
• 書き出し先は 移行するディスク自身とは別のドライブ（今回は外付けの大容量HDD）にする

これで数十GBのVHDXファイルが1つできあがる。これが引っ越しの「引っ越しトラック」になる。

【つまずきポイント】書き出し先を間違えて元ディスクと同じ場所を指定すると、当然ながら容量が足りず失敗する。必ず別ドライブへ。外付けHDDや、後述するNAS用に用意した大容量ディスクを一時保管先に使うとよい。

手順② Proxmoxへディスクをインポート――そして容量切れ事件

VHDXができたら、Proxmox側へ取り込む。Proxmoxには物理／仮想ディスクイメージをVMのディスクとして取り込む qm importdisk というコマンドがある。

# 書式: qm importdisk <VMID> <イメージファイル> <保存先ストレージ>
qm importdisk 100 /mnt/backup/UENO-HOME.vhdx local-lvm

ここで最初の大きな地雷を踏んだ。インポート先に指定した local-lvm（ProxmoxのシステムSSD上のthinプール）の容量が足りず、途中で止まってしまった のだ。

thinプロビジョニング（実際に使った分だけ消費する方式）とはいえ、VHDXの実データ量がプールの物理容量に収まらなければ当然あふれる。システムSSDは容量が限られているので、OSまるごとのイメージを置くには手狭だった。

対処方法

インポート先を、NAS用に増設した NVMe SSD側の大容量thinプール に変更して取り込み直した。ストレージには用途に応じた余裕を持たせておくことの大切さを、いきなり痛感させられた。

【つまずきポイント】importdisk は「どのストレージに置くか」を最後の引数で指定する。ここをシステムSSD（容量小）にすると容量切れになりやすい。VMのメインディスクは、最初から大容量プールを指定するのが安全だ。

手順③ GPTバックアップテーブル破損からの復旧

ディスクのインポート自体は通ったが、次はディスクの整合性でつまずいた。物理ディスクと仮想ディスクではセクタ数・末尾の位置が微妙にずれるため、GPT（GUIDパーティションテーブル）のバックアップ（副）テーブルが「ディスク末尾にない」状態 になり、警告が出た。

GPTはパーティション情報をディスクの先頭（主）と末尾（副）の2箇所に持っている。イメージ移行でディスクサイズが変わると、末尾の副テーブルの位置がずれてしまうのだ。

対処方法

gdisk でディスクを開き、副GPTをディスク末尾へ再配置して書き直すことで復旧できた。パーティションの中身（データ）自体には手を触れず、あくまでテーブルの位置情報を修復するだけなので、正しく操作すればデータは失われない。

【つまずきポイント】この警告を放置したままだと、後のブートでファームウェアがパーティションをうまく認識できず、起動不能の一因になる。移行後にディスク関連の警告が出たら、先に潰しておくのが安全だ。

手順④ ブートループとの格闘――UEFI/OVMFの設定

ディスクが整ったら、いよいよ起動。ところがここでも一筋縄ではいかなかった。移行元のWindowsは UEFIブート だったので、VM側もそれに合わせる必要がある。

Proxmoxで押さえるべき設定は次のとおり。

設定項目	値
BIOS	OVMF (UEFI)
マシン種別	q35
EFI Disk	追加する（UEFI設定の保存先）
ブート順	移行したディスクを先頭に

これが噛み合わないと、延々とブートループに陥る。BIOSが「レガシー（SeaBIOS）」のままだったり、EFI Diskを付け忘れたりすると、Windowsのブートローダーにたどり着けない。

手順⑤ 起動はするのに画面が真っ黒――OVMF NVRAM破損

設定を合わせて、ようやく起動……と思いきや、今度は VMのCPU使用率が100%に張り付いたまま、画面がずっと真っ黒 という状態になった。コンソールには「Guest has not initialized the display（ゲストはまだ画面を初期化していません）」とだけ表示される。

CPUタイプを変えても、待ち続けても変わらない。OS以前に、UEFIファームウェア（OVMF）そのものが、画面を描画する前の段階でループしていた。

原因

OVMFのUEFI設定（ブート順やセキュアブートの状態）を保存している efidisk（NVRAM）が壊れていた。ホストのアップグレードやディスク周りの再構成をきっかけに、保存済みのNVRAMとファームウェアの間で不整合が起き、起動時にハングしていたのだ。

対処方法

efidiskを 一度削除して作り直す（NVRAMをリセットする） ことで解決した。

# VMを停止
qm stop 100

# 壊れたefidiskを削除
qm set 100 --delete efidisk0

# efidiskを作り直す（NVRAMリセット・データディスクには触れない）
qm set 100 --efidisk0 local-lvm:0,efitype=4m,pre-enrolled-keys=0

# 起動
qm start 100

作り直した直後にWindowsが自動修復を走らせ「修復できませんでした」と一度は表示したが、回復メニューから「続行」を選ぶと、そのまま通常起動してロック画面までたどり着いた。自動修復の失敗表示は過剰反応で、本当の原因はNVRAMだけだった、というオチだ。

【つまずきポイント】efidiskはあくまで「UEFI設定を入れる4MBの小さな箱」で、Windows本体やデータが入っているディスク（今回はSATA接続のメインディスク）とは別物。作り直してもデータは消えない。黒画面＋100%CPU＋「display not initialized」の三点セットが出たら、まずNVRAMリセットを疑うとよい。

手順⑥ 起動してもネットに繋がらない――virtioドライバ問題

無事デスクトップにログインできて一安心……したのも束の間、今度は インターネットに繋がらない。ホスト側のネットワークもブリッジも正常、なのにWindowsからは外に出られない。

原因

これは物理マシンからの移行あるある。Proxmoxの標準仮想NIC「virtio」は高速だが、物理マシン由来のWindowsにはvirtio用のドライバが入っていない。そのためWindowsからはネットワークアダプタが「正体不明のデバイス」に見え、そもそも認識できていなかった。

対処方法

NICのモデルを、Windowsが標準ドライバを最初から持っている e1000（Intel） に変更して再起動した。

# NICをvirtio → e1000へ（MACはそのまま維持）
qm set 100 --net0 e1000=<元のMACアドレス>,bridge=vmbr0

# VMを再起動
qm reboot 100

再起動後、Windowsは即座にe1000アダプタを認識し、ルーターからDHCPでIPアドレスを取得。ブラウザで問題なくサイトが開くようになった。

【つまずきポイント】速度を重視して最終的にvirtioに戻したい場合は、先に「virtio-win」ドライバISOをWindowsにインストールしてからNICモデルを戻すこと。まず繋がることを優先するなら、e1000がいちばん手っ取り早い。

今回のまとめ：P2Vつまずきポイント一覧

• Disk2VHDの書き出し先は、移行元ディスクとは別のドライブにする
• qm importdisk の保存先はシステムSSDではなく大容量プールを指定（容量切れ回避）
• 移行後にGPTの副テーブル破損警告が出たらgdiskで先に修復しておく
• UEFI移行なら BIOS=OVMF・q35・EFI Disk追加・ブート順を揃える
• 100%CPUで黒画面＋「display not initialized」はOVMFのefidisk（NVRAM）を作り直す
• 物理由来Windowsがネット不通なら、NICをvirtio→e1000へ変更する

「バックアップを取ってインポートするだけ」のはずが、フタを開ければ容量・ディスク・ファームウェア・ドライバと、レイヤーの違う問題が次々に出てきた。だが裏を返せば、これらは物理から仮想へ移すときに誰もが踏みうる定番の地雷でもある。同じ引っ越しをする人の道しるべになれば嬉しい。

次回は最終回。ここまでの自作NAS計画を振り返り、「結局、自作NASは市販NASより本当に安かったのか」 を、かかった費用と手間の両面から総括する。