IBM Cloud VPC への Windows 移行に関する考慮事項：ドライバー、ライセンス、および準備

IBM Cloud VPC への Windows 移行に関する考慮事項（ VirtIO によるドライバーの注入、Sysprep による準備、およびライセンス要件など）を確認してください。

ドライバーの課題

VMware 環境では、Windowsは VMware 準仮想化ドライバ（ネットワーク用 vmxnet3、ストレージ用pvscsiなど）をロードし、特定のハードウェア識別子にバインドする。 ディスクをVPCに移すと、ハードウェアが変わります：

  • ネットワーク： VMware vmxnet3 → 仮想I/O（ VirtIO ）ネットワークアダプタ
  • ストレージ（ブート）： VMware PVSCSI → VirtIO SCSI アダプタ
  • ストレージ（データ）： VMware PVSCSI → VirtIO ブロックアダプター

Windowsが起動し、ブートストレージコントローラーのハードウェアIDが異なると、起動に失敗する（INACCESSIBLE_BOOT_DEVICEブルースクリーン）。

解決策 A：Sysprep によるアプローチ

マイクロソフトの sysprep ユーティリティは、ウィンドウズのインストールを「一般化」し、最初の起動状態にリセットする。 これだ：

  • ドライバーのバインディングを解除
  • Windowsのセキュリティ識別子（SID）をリセットします
  • コンピュータ固有の情報を削除する
  • 再展開のためのイメージの準備

sysprep について、以下のプロセスを完了する：

  1. VMware でホストされている間に、Windows 仮想マシンに VirtIO ドライバをインストールする：

    1. RHEL仮想サーバーインスタンス（/usr/share/virtio-win ）からvirtio-winのISOイメージをダウンロードします。
    2. ISOをマウントし、 virtio-win-gt-x64.exe、 virtio-win-guest-tools.exe を実行する。
    3. OSとリカバリーパーティションの両方にドライバをインストールする。

  2. sysprepを実行する：

    C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdown

  3. VDDK Direct Extraction（ vCenter ）を除き、どの 移行方法でも エクスポートおよび移行が可能です。

  4. VPCでの最初のブート：

    • Windowsはミニセットアップウィザード（OOBE）を実行します
    • 新しいハードウェアを検出し、 VirtIO ドライバをロードします
    • プロダクトキーの再入力が必要な場合がある
    • ドメインに再加入する必要があるかもしれない

利点:

  • 文書化されたマイクロソフトのプロセス
  • Windowsのデプロイでも確実に動作

欠点:

  • マシンのIDをリセットする（ドメインに参加しているサーバーでは問題がある）
  • Windowsの再起動を引き起こす可能性がある
  • アプリケーション固有の問題（sysprepをうまく扱えないアプリケーションもある）
  • 初回起動時にOOBEの完了が必要

設計上の決定テンプレートベースのデプロイメントや、ID リセットが許容される開発用またはテスト用の仮想マシンに移行する場合は、sysprep を使用します。 複雑なアプリの依存関係がある、ドメイン結合された本番サーバーでは避けてください。

解決策 B： virt-v2v ドライバーの注入

libguestfs virt-v2v ツールは、sysprep を実行することなく、Windows インストールに VirtIO ドライバを注入することができる。 それだ：

  • Windowsファイルシステムをマウントする（Windowsを起動しない）
  • VirtIO ドライバをドライバストアに注入する
  • レジストリを変更し、Windowsにこれらのドライバを強制的にロードさせる
  • マシンID、ドメインメンバーシップ、アプリケーションの状態を保持

前提条件:

  • 仮想マシンをきれいにシャットダウンすること（クラッシュしたり、強制終了したりしないこと）
  • Windowsのバージョンがサポートされていること（Server 2008 R2 ～2025、Windows 7～11）
  • Virtio-win ドライバーパッケージ (RHEL システムで利用可能: /usr/share/virtio-win)

以下は、 virt-v2v ドライバーインジェクションの手順である：

  1. Windowsのブートパーティションとリカバリパーティションに VirtIO ドライバをインストールする（sysprepのアプローチと同じ）

  2. Windows仮想マシンをクリーンにシャットダウンする

  3. いずれかの 移行方法 を使用して、ディスクをワーカー仮想サーバーインスタンスにエクスポートまたは移行します。

  4. 走る virt-v2v:

    virt-v2v -i disk windows-vm.img -o disk -os /target --block-driver virtio-scsi

    パラメーター:

    • -i disk:入力はディスクイメージファイル
    • -o disk -os /target:ディレクトリに出力
    • --block-driver virtio-scsi:最初のディスクに SCSI ドライバを使用 (VPC ブートボリュームに必要)

  5. デバイスに直接書き込む場合：

    ln -fs /dev/vdb /target/windows-vm-sda
virt-v2v -i disk windows-vm.img -o disk -os /target --block-driver virtio-scsi

の利点 virt-v2v:

  • マシンの同一性を保持（再アクティベーション、再ドメイン結合なし）
  • ファーストブート・セットアップ・ウィザードがない
  • アプリケーションの状態そのまま
  • 本番サーバーで動作

欠点:

  • RHEL/ Ubuntu のハイブリッド・セットアップが必要
  • シスプレップより複雑
  • クリーンシャットダウンが必要（クラッシュ/強制終了した仮想マシンを処理しない）

設計上の決定 virt-v2v、アイデンティティの保持が重要な本番Windowsサーバーに使用する。 ツールの複雑さは、よりクリーンな移行のためのトレードオフとして受け入れる。

RHEL／ Ubuntu の課題

重要な問題：VPC上のWindows仮想マシンでは、「 --block-driver virtio-scsi 」オプションが必須です（ブートディスクは VirtIO ブロックではなく、Virtual I/O（ VirtIO ）SCSIを使用します）。しかし、以下の点に注意してください：

  • RHEL virt-v2v はサポートしていません。 --block-driver virtio-scsi
  • Ubuntu virt-v2v サポート --block-driver virtio-scsi
  • RHEL の libguestfs には virtio-win のドライバが含まれています。 /usr/share/virtio-win
  • Ubuntu libguestfs は virtio-win ドライバを含まない

回避策

RHEL/ Ubuntu の問題には2つの回避策がある。

オプション 1: libguestfs のビルド Ubuntu

最初のオプションは、以下のコマンドを実行して Ubuntu で libguestfs をビルドすることである。

# On Ubuntu worker virtual server instance
apt-get install libguestfs-tools
# Copy virtio-win from a RHEL system
# On RHEL: tar czf virtio-win.tar.gz /usr/share/virtio-win
# Transfer to Ubuntu and extract:
tar xzf virtio-win.tar.gz -C /usr/share/
# Now virt-v2v on Ubuntu has both SCSI support and drivers
virt-v2v -i disk windows.img -o disk -os /target --block-driver virtio-scsi

オプション2：2段階変換

つ目のオプションは、以下のコマンドを使って2段階変換を行うことである。

# On RHEL worker (has drivers, no SCSI support)
virt-v2v -i disk windows.img -o disk -os /tmp
# Transfer to Ubuntu worker
scp /tmp/windows-sda ubuntu-worker:/tmp/
# On Ubuntu worker (has SCSI support)
virt-v2v -i disk /tmp/windows-sda -o disk -os /target --block-driver virtio-scsi

VPCにおけるWindowsストレージドライバーのアーキテクチャ

VPCがWindowsにストレージをどのように見せるかを理解することは、ブート問題のトラブルシューティングに役立ちます：

最初のボリューム（ブートディスク）：

  • VirtIO SCSI デバイスとして表示
  • virtio-scsi ドライバが必要
  • これが、 --block-driver virtio-scsi が必須である理由だ

後続ボリューム（データディスク）：

  • VirtIO ブロックデバイス
  • virtio-blkドライバが必要
  • 起動ディスクと異なるドライバ

両方のドライバーをインストールする必要があります：

  • 実行中のOS
  • リカバリー環境 ( WinRE )

リカバリ環境でのドライバのインストール

Windows リカバリ環境（ WinRE ）は、リカバリ操作に使用される独立したミニ Windows 環境です。 仮想I/O（ VirtIO ）ドライバが搭載されていない場合、移行後の復旧には使用できません。

場所 WinRE:

reagentc /info

リカバリーボリュームが報告されるかもしれないが、実際の WinRE ：

C:\Windows\System32\Recovery\winre.wim

ドライバのインストール WinRE:

  1. virtio-win ISOをマウントする

  2. WinRE。 reagentc /info

  3. 別ボリュームにある場合は、一時的にマウントする

  4. DISMを使用してドライバーを注入する：

    dism /mount-wim /wimfile:C:\Windows\System32\Recovery\winre.wim /index:1 /mountdir:C:\mount
dism /image:C:\mount /add-driver /driver:E:\viostor\w10\amd64 /recurse
dism /image:C:\mount /add-driver /driver:E:\netkvm\w10\amd64 /recurse
dism /unmount-wim /mountdir:C:\mount /commit

GPTパーティションに関する考察：

Windowsディスクが（MBRではなく）GPTを使用している場合：

  • の代わりに list volume と select volume を使う。 list partition
  • ボリュームIDの設定は異なります：
    • データ量： set id=ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
    • システムボリューム： set id=c12a7328-f81f-11d2-ba4b-00a0c93ec93b

対応している Windows のバージョン

Red Hat のvirtio-winパッケージは、以下のドライバを提供する：

Windows Server：

  • 2008年 R2
  • 2012年、2012年 R2
  • 2016年、2019年、2022年、2025年

Windowsクライアント：

  • 7
  • 8, 8.1
  • 10
  • 11

古いバージョン（Server 2003、2008 non-R2、Vista）には対応していません。

次の表は、Windowsの設計決定マトリックスである

ウィンドウズの設計決定マトリックス
シナリオ 推奨されるアプローチ
開発/テスト用仮想マシン シスプリ（シンプル、IDリセット可）
本番用スタンドアロン・サーバー virt-v2v (同一性を保つ）
ドメイン結合された本番サーバー virt-v2v (ドメイン再参加を避ける）
テンプレートベースのデプロイメント シスプレップ（テンプレートに適している）
ハードウェアIDに関連付けられたライセンスを持つサーバー virt-v2v + 免許の見直しを慎重に
古いウィンドウズ (2003, 2008 non-R2 ) マイグレーションには非対応