はじめに
前回の記事では、croit/load-virtio-scsi-on-boot スクリプトを ESXi 上で事前実行してから Proxmox VE に SATA としてインポートし、その後 SATA → VirtIO SCSI（scsi0）に切り替える方法で、ダミーディスクなしの VirtIO SCSI ブートに成功しました。
その検証中にひとつの疑問が生まれました。croit スクリプトで vioscsi ドライバがブート時ロード可能な状態になっているなら、Import Wizard でわざわざ SATA を経由せず、最初から VirtIO SCSI（scsi0）としてインポートすればそのまま起動するのではないか？ という点です。
結論を先に書くと、scsi0 での直接インポートでも BSOD なしで起動に成功しました。 ただし、SATA 経由のパターンと比較して転送時間が約 10 分長くなり、NIC ドライバの修復インストールが必要でした。本記事ではこの検証結果を報告するとともに、シリーズ全 5 回の総括比較を行います。
対象読者
- 前回記事で croit スクリプト + SATA 経由を試した方
- Import 後の SATA → scsi0 変換手順を省略したい方
- シリーズ全体の比較結果を知りたい方
シリーズ記事
| # | 記事 | 概要 |
|---|---|---|
| 1 | VirtIO 事前未導入パターン | SATA で Import → ダミーディスク方式で VirtIO SCSI 化 |
| 2 | VirtIO 事前導入パターン | ESXi で MSI 事前インストール → BSOD → ダミーディスク方式 |
| 3 | pnputil・レジストリ手動作成の検証 | pnputil・レジストリ・sys コピーすべて失敗、差分ゼロ |
| 4 | croit スクリプトで SATA 経由の VirtIO SCSI ブート | croit スクリプトでダミーディスクなし VirtIO SCSI ブートに成功 |
| 5 | 本記事 | croit スクリプト適用後に scsi0 で直接インポート |
前提条件
テスト環境は前回と同一です。ESXi 上の VM は前回の記事で croit スクリプトを適用した状態のまま停止しており、今回はその VM を再利用しています。
| 項目 | スペック |
|---|---|
| 物理ホスト | AMD Ryzen 5 5600G / 128 GB RAM / 8.8 TB NVMe + 7.2 TB HDD / 2.5 GbE NIC |
| Proxmox VE | 9.1.6（kernel 6.17.13‑2‑pve）/ ZFS 5.81 TB + LVM 150 GB |
| Nested ESXi | 6.7 U2（VMID 101 / 6 vCPU / 32 GB RAM / IP: 192.168.11.55） |
| 移行対象 VM | Windows Server 2025 Datacenter（評価版）/ 4 vCPU / 4 GB RAM / 40 GB thin disk / LSI Logic SAS / EFI / Intel 82574L NIC |
| VirtIO ドライバ | virtio-win-gt-x64.msi（stable 版）インストール済み |
| croit スクリプト | 前回記事で実行済み（Services\vioscsi Start=0 設定済み） |
手順 1：前回の VM 126 を削除
前回の検証で作成した Proxmox VM 126 を削除し、クリーンな状態にします。
qm stop 126
qm destroy 126 --purge
手順 2：Import Wizard の設定
Proxmox の Web UI から Import Wizard を起動し、ESXi ストレージ（esxi67）から WinSV2025 を選択します。
前回（記事 4）との設定の違いは以下の通りです。
| 設定項目 | 記事 4（SATA 経由） | 今回（scsi0 直接） |
|---|---|---|
| ディスク | sata1（SATA） | scsi0（VirtIO SCSI） |
| VirtIO-SCSI の準備 | チェックあり | チェックなし |
| SCSI コントローラ | VirtIO SCSI single | VirtIO SCSI single |
| NIC | VirtIO | VirtIO |
| Live Import | 有効 | 有効 |
ポイントは、ディスクを最初から scsi0（VirtIO SCSI）として設定し、「VirtIO-SCSI の準備」チェックを外している点です。croit スクリプトで vioscsi ドライバが既にブート時ロード可能な状態になっているため、SATA を経由する必要がないという仮説に基づいています。
手順 3：Live Import の実行と経過
Import を開始すると、タスクログに restore-scsi0 と表示されます。前回までの restore-sata1 ではなく、最初から VirtIO SCSI としてディスク転送が行われていることがわかります。
3-1. ローカルセッションマネージャーの処理
転送開始から約 17 分後、VM コンソールに「ローカル セッション マネージャー の処理が完了 ください」と表示されました。この時点で転送率は約 23.5%（9.4 GiB / 40.0 GiB）です。
BSOD は発生していません。VirtIO SCSI 経由でディスクを読み取りながら Windows が起動処理を進めていることがわかります。
3-2. ロック画面の表示
転送開始から約 19 分 20 秒後、ロック画面が表示されました（時刻 9:35、2026 年 4 月 17 日）。転送率は約 23.6%（9.5 GiB / 40.0 GiB）です。
前回（記事 4、SATA 経由）ではロック画面表示までの具体的な時間を計測していませんでしたが、Live Import のログイン画面表示タイミングとしては通常の範囲内です。
3-3. Administrator ログイン画面
ロック画面で Ctrl+Alt+Del を送信すると、Administrator のログイン画面が表示されました。タスクログでは転送率約 27.6〜28.7%（11.0〜11.5 GiB / 40.0 GiB）、経過時間 22 分 15 秒〜22 分 38 秒です。
3-4. 転送完了
ログインしてサーバーマネージャーが表示された後も転送はバックグラウンドで継続し、最終的に 32 分 39 秒 で 40.0 GiB の転送が完了しました。
タスクログの最終行：
restore-scsi0: transferred 40.0 of 40.0 GiB (100.00%) in 32m 39s
restore-scsi0: stream-job finished
restore-drive jobs finished successfully, removing all tracking block devices
TASK OK
手順 4：NIC ドライバの修復
4-1. デバイスマネージャーの確認
ログイン後、デバイスマネージャーを確認すると、「ほかのデバイス」カテゴリに「PCI デバイス」と「イーサネット コントローラー」が警告アイコン付きで表示されていました。ネットワークアダプターのカテゴリ自体が存在しません。
記憶域コントローラーには Red Hat VirtIO SCSI pass-through controller が 2 つ表示されています（1 つは croit スクリプトが作成したファントムデバイス）。
この NIC ドライバ未認識の現象は、記事 2（MSI 事前導入パターン）でも発生しました。VirtIO NIC（NetKVM）ドライバは MSI でインストールされているものの、ESXi 上では Intel 82574L（E1000E）NIC が使われていたため、VirtIO NIC に対するドライバの関連付けが行われていない状態です。
4-2. MSI の修復インストール
転送完了（TASK OK）を待ってから、virtio-win-gt-x64.msi の修復インストールを実行しました。
「Repair」を選択して実行すると、Setup Wizard が完了し、デバイスマネージャーに「ネットワーク アダプター」カテゴリが出現、Red Hat VirtIO Ethernet Adapter が認識されました。
手順 5：ネットワークの確認
5-1. ipconfig /all
ホスト名. . . . . . . . . . . . .: WIN-M3U1IDLMGOC
プライマリ DNS サフィックス . . . .:
ノード タイプ . . . . . . . . . . .: ハイブリッド
IP ルーティング有効 . . . . . . . .: いいえ
WINS プロキシ有効 . . . . . . . . .: いいえ
イーサネット アダプター イーサネット:
接続固有の DNS サフィックス . . . .:
説明. . . . . . . . . . . . . . .: Red Hat VirtIO Ethernet Adapter
物理アドレス. . . . . . . . . . .: 00-0C-29-29-F8-5A
DHCP 有効 . . . . . . . . . . . .: はい
自動構成有効. . . . . . . . . . .: はい
IPv6 アドレス . . . . . . . . . .: 2001:348:451f:5000:593a:6eda:404c:15bb(優先)
リンクローカル IPv6 アドレス . . .: fe80::52f1:6f6c:6032:3094%7(優先)
IPv4 アドレス . . . . . . . . . .: 192.168.11.151(優先)
サブネット マスク . . . . . . . .: 255.255.255.0
リース取得 . . . . . . . . . . .: 2026年4月17日 9:51:43
リースの有効期限 . . . . . . . .: 2026年4月17日 13:51:43
デフォルト ゲートウェイ . . . . .: fe80::124b:46ff:feed:4cc5%7
192.168.11.1
DHCP サーバー . . . . . . . . . .: 192.168.11.1
DHCPv6 IAID . . . . . . . . . . .: 117443625
DHCPv6 クライアント DUID . . . . .: 00-01-01-00-31-71-D1-EE-00-0C-29-29-F8-5A
DNS サーバー . . . . . . . . . . .: 2001:348:451f:5000:124b:46ff:feed:4cc5
192.168.11.1
NetBIOS over TCP/IP . . . . . . .: 有効
5-2. ping 8.8.8.8
C:\Users\Administrator>ping 8.8.8.8
8.8.8.8 に ping を送信しています 32 バイトのデータ:
8.8.8.8 からの応答: バイト数 =32 時間 =18ms TTL=117
8.8.8.8 の ping 統計:
パケット数: 送信 = 1、受信 = 1、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 18ms、最大 = 18ms、平均 = 18ms
VirtIO NIC 経由でネットワーク通信が正常に行えることを確認しました。
手順 6：ファントムデバイスの削除
記憶域コントローラーに表示されている 2 つの Red Hat VirtIO SCSI pass-through controller のうち、croit スクリプトが作成したファントムデバイス（ROOT\VIOSCSI\0000）を右クリック →「デバイスのアンインストール」で削除しました。
削除後のデバイスマネージャーでは、記憶域コントローラーに Red Hat VirtIO SCSI pass-through controller が 1 つ（正常動作中のもの）のみとなり、ネットワークアダプターに Red Hat VirtIO Ethernet Adapter が表示されています。警告アイコンはありません。
手順 7：Proxmox 側のクリーンアップ
不要な sata0（空の CD-ROM）を削除し、ブート順を scsi0 のみに設定します。
qm set 126 --delete sata0
qm set 126 --boot order=scsi0
qm config 126
最終構成の出力：
bios: ovmf
boot: order=scsi0
cores: 4
cpu: host
efidisk0: local-zfs:vm-126-disk-0,efitype=4m,size=1M
machine: pc-i440fx-10.1
memory: 4096
meta: creation-qemu=10.1.2,ctime=1776384972
name: WinSV2025
net0: virtio=00:0c:29:29:f8:5a,bridge=vmbr0
ostype: win10
scsi0: local-zfs:vm-126-disk-1,size=40G
scsihw: virtio-scsi-single
smbios1: uuid=564dc5a8-0ede-fd94-3c01-c1f42d29f85a
sockets: 1
vmgenid: fe7a19d7-c1e1-48d5-a261-bb2c900c5415
不要なデバイスがなく、scsi0（VirtIO SCSI、40 GB）+ VirtIO NIC のみのクリーンな構成です。
検証結果
scsi0 直接インポートは成功しました。以下に確認結果をまとめます。
| 確認項目 | 結果 |
|---|---|
| BSOD | 発生なし |
| ブートディスク | scsi0（VirtIO SCSI） |
| 転送時間 | 32 分 39 秒 |
| ロック画面表示 | 転送開始から約 19 分 20 秒（転送率 約 23.6%） |
| NIC（VirtIO） | MSI 修復インストール後に認識 |
| ファントムデバイス | 手動アンインストールで削除 |
| ipconfig /all | 192.168.11.151（DHCP）、Red Hat VirtIO Ethernet Adapter |
| ping 8.8.8.8 | 18 ms、損失 0% |
| ダミーディスク | 不要 |
| SATA → scsi0 変換 | 不要 |
シリーズ全体の比較
5 回の検証結果を一覧で比較します。
| # | パターン | ESXi 側の事前準備 | Import 時のディスク | 転送時間 | ダミーディスク | 変換手順 | NIC 修復 | 結果 |
|---|---|---|---|---|---|---|---|---|
| 1 | VirtIO 未導入 | なし | SATA | 26 分 22 秒 | 必要 | SATA→scsi0 | 不要 | 成功 |
| 2 | MSI 事前導入 | MSI のみ | SATA | 22 分 47 秒 | 必要 | SATA→scsi0 | 修復要 | 成功 |
| 3 | pnputil・レジストリ手動 | MSI + 手動設定 | SATA | — | — | — | — | 失敗（BSOD） |
| 4 | croit + SATA 経由 | MSI + croit | SATA | 21 分 51 秒 | 不要 | SATA→scsi0 | 不要 | 成功 |
| 5 | croit + scsi0 直接 | MSI + croit | scsi0 | 32 分 39 秒 | 不要 | 不要 | 修復要 | 成功 |
各パターンの特徴
パターン 1（VirtIO 未導入、ダミーディスク方式） は、ESXi 側での事前準備が不要で、手順が Proxmox 公式 Wiki やブログにも記載されています。ダミーディスクの追加・削除はコマンド数行で完了し、実質的な手間は小さいです。NIC ドライバの修復も不要で、最も安定した方法です。
パターン 2（MSI 事前導入） は、MSI を事前にインストールしても結局ダミーディスクが必要で、さらに NIC の修復インストールも必要になります。MSI 事前導入のメリットは薄いと言えます。
パターン 3（pnputil・レジストリ手動作成） は、すべての試行で BSOD が発生し失敗しました。Windows PnP マネージャーの内部処理にはレジストリだけではアクセスできない状態があることが判明しています。
パターン 4（croit + SATA 経由） は、ダミーディスク手順が不要になる唯一の方法で、転送時間も最短の 21 分 51 秒です。ただし ESXi 上で GitHub のサードパーティスクリプトを事前実行する必要があり、Import 後に SATA → scsi0 の変換手順（コマンド 3 行）は残ります。NIC の修復は不要でした。
パターン 5（croit + scsi0 直接） は、ダミーディスクも SATA → scsi0 変換も不要で、Import 後の手順が最もシンプルです。ただし転送時間が 32 分 39 秒と最長で、NIC の修復インストールが必要です。VirtIO SCSI 経由での転送はオーバーヘッドが大きい可能性があります。
補足事項
すべてのパターンに共通して、croit スクリプト適用後はファントムデバイス（ROOT\VIOSCSI\0000）が残るため、Windows 側での手動削除が必要です。
NIC の修復インストールが必要になるかどうかは、Import 時のディスク方式ではなく、ESXi 上での NIC ドライバの状態に依存していると考えられます。パターン 1 では Import 後に MSI を新規インストールするため修復は不要でしたが、パターン 2 と 5 では ESXi 上で MSI をインストール済みだったため修復が必要でした。パターン 4 で修復が不要だった理由は、前回の検証で既にインポート → 修復の過程を経ていた VM を再利用したためと推定されます。
まとめ
croit スクリプトを適用した VM を VirtIO SCSI（scsi0）で直接インポートする方法は、技術的には動作します。BSOD は発生せず、ダミーディスクも SATA → scsi0 変換も不要です。
ただし、転送時間が SATA 経由と比較して約 10 分長くなる点と、NIC ドライバの修復インストールが必要な点はデメリットです。
5 回の検証を通じて、どの方法が「最善」かは一概には言えません。以下の観点で読者の環境や優先事項に合わせて選択するのがよいでしょう。
| 優先事項 | 推奨パターン |
|---|---|
| 公式手順に準拠したい・外部スクリプトを使いたくない | パターン 1（ダミーディスク方式） |
| 転送時間を最短にしたい | パターン 4（croit + SATA 経由） |
| Import 後の手順を最小にしたい | パターン 5（croit + scsi0 直接） |
| 大量の VM を自動化したい | パターン 4 または 5（スクリプト化しやすい） |