今回は、VirtualBox 上で動いていた AlmaLinux の仮想マシンを、Clonezilla を使って Proxmox 上の仮想マシンへ移行した際に、起動できずに詰まった話です。
移行自体は完了したように見えたものの、起動時に dracut-initqueue timeout が出続け、OS が正常起動しませんでした。
最終的には、Proxmox 側の仮想ディスク接続方式の違いっぽい感じで、既存ディスクを SATA で再接続する ことで復旧できました。
また、切り分けの過程で、Proxmox の Web 管理画面からはディスクのデタッチまではできたものの、SATAでの再アタッチのやり方が分かりづらく、最終的に CLI で対応した という点も、地味にハマりどころでした。
同じように VirtualBox から Proxmox へ V2V しようとしている人の参考になればと思い、記録を残します。
設定内容やプログラムの内容は、用途・環境に応じて適切なものが変わります。
各種設定値や環境情報についてよく理解を深め、壊れても良い環境でくまなく検証してください。
なるべく正確に書くように心掛けていますが、本投稿内容を実施される際には自己責任の下でお願い致します。
事象
移行元・移行先は以下のような構成です。
- 移行元: VirtualBox 上の AlmaLinux
- 移行先: Proxmox VE 上の仮想マシン
- 移行方法: Clonezilla を用いた V2V
移行後、Proxmox 上で仮想マシンを起動すると、次のようなメッセージが表示されて停止しました。
dracut-initqueue[428]: Warning: dracut-initqueue timeout - starting timeout scripts
OS が起動処理の途中で止まり、正常にログインできない状態でした。
原因の見立て
今回の Proxmox 側の設定は以下の通りでした。
- BIOS: SeaBIOS
- Machine: i440fx
- ディスク:
scsi0 - SCSI Controller:
VirtIO SCSI single
一方、移行元の VirtualBox では、Proxmox の VirtIO SCSI を前提にした構成ではありません。
そのため、Clonezilla でディスク内容そのものは移行できていても、起動直後に必要なストレージドライバや initramfs の内容が、移行先の仮想ハードウェアに追従できていない 状態になっていたと考えられます。
つまり、OS から見ると移行前後で起動ディスクの見え方が変わっており、dracut が root ファイルシステムを見つけられず、dracut-initqueue timeout になっていると推測。
切り分け方針
最初に確認した Proxmox 上のハードウェア構成は次のようなものでした。
scsi0: local-lvm:vm-136-disk-0scsihw: virtio-scsi-single
この時点で、VirtualBox 由来のゲスト OS に対しては少し怪しいと判断しました。（Proxmox上で仮想マシン作る時点で、SATAにしとけばハマらずに済んだ。。。）
そこで、まずは VirtIO SCSI をやめて、既存ディスクを SATA で再接続して起動確認する 方針にしました。
Web 管理画面でやってみたこと
まずは Proxmox の Web 管理画面からSATA接続に変えるためディスクを操作しました。
ディスクのデタッチ自体は問題なくできたのですが、その後の 再アタッチ方法がすぐには分かりませんでした。
感覚的には「外したディスクをそのまま別のバスで付け直す」操作を想定していたのですが、Web UI 上では見つからず、どこから既存ディスクを SATA として再アタッチしたらよいか迷いました。
Proxmox のバージョンや自分が見つけられなかっただけかもしれませんが、ここは CLI で qm set を使った方が早い と判断しました。
実際の対処
1. 現在の VM 設定を確認
まずは Proxmox ノード上で、対象 VM の設定を確認しました。
qm config 136
この時点では、対象ディスクはもともと local-lvm:vm-136-disk-0 でした。
2. 既存ディスクを SATA で再アタッチ
その後、既存ディスクを sata0 として再接続しました。
qm set 136 --sata0 local-lvm:vm-136-disk-0
あわせて、ブート順も sata0 を優先するように設定しました。
qm set 136 --boot order=sata0
最終的な設定は以下のようになりました。
boot: order=sata0;ide2;net0
sata0: local-lvm:vm-136-disk-0,size=80G
3. 起動確認
この状態で VM を起動します。（ここはWebUIからやってもよかったかも。。。）
qm start 136
すると、無事に起動しました。
ここで分かったこと
今回の直接原因は、VirtualBox から Clonezilla で持ってきた AlmaLinux が、Proxmox の VirtIO SCSI 構成では起動時にディスクを正しく認識できなかったこと でした。
そして実務上のハマりどころとして、「SCSI が怪しいので SATA で試そう」と思っても、Web 管理画面だけでスムーズに再アタッチできるとは限らない という点もありました。
今回のようなケースでは、むしろ最初から CLI で下記のようにコマンド叩いたほうが早そうです。（仮想マシンのIDである136は環境によって書き換えて下さい）
qm config 136
qm set 136 --sata0 local-lvm:vm-136-disk-0
qm set 136 --boot order=sata0
今回の教訓と学び
今回の件での学びは次の2点です。
まず、Clonezilla でディスク内容を移行できても、移行先の仮想ハードウェア差分までは自動で吸収してくれない ということです。
特に VirtualBox から Proxmox のように、ディスクバスや仮想デバイスの前提が変わるケースでは、起動後の見え方が変わることを前提に切り分けた方がよさそうです。
もうひとつは、Proxmox の Web UI でデタッチできても、再アタッチすることがWebUIからは出来ないっぽい感じ。
既存ディスクを別バスで付け直すような作業では、CLI の qm set の方が早そう。
まとめ
VirtualBox 上の AlmaLinux を Clonezilla で Proxmox へ移行したところ、dracut-initqueue timeout で起動できませんでした。
原因は、Proxmox 側でディスクを VirtIO SCSI として接続していたことで、移行元環境との差分を initramfs が吸収できていなかったためと考えられます。
対処としては、既存ディスクを一旦 SATA で再アタッチし、ブート順を変更することで無事起動できました。
また、ディスクのデタッチ自体は Proxmox の Web 管理画面から実施できたものの、再アタッチは分かりづらく、最終的には qm set を使った CLI 操作で解決しました。
同じような移行で詰まった場合は、まず「Clonezilla の失敗」よりも先に、「移行先の仮想ディスク接続方式」を疑い、必要なら CLI での再アタッチも視野に入れるとよさそうです。