ZFS、iSCSI、PXEを使用したディスクレスLinuxブート

1日前原文(aniket.foo)

概要

Windows環境を汚さずにUnslothモデルのテストを行いたい動機
PXE+iSCSIによるリモートブート環境の構築手順
ProxmoxとZFS、iSCSI Targetを活用した構成
DNSMasqやTFTPなどネットワークブートに必要な設定
Debianのインストールまでの一連の流れを簡潔に解説

Windows環境を汚さずにLLMテスト用Linuxをリモートブートする動機

Windows 上で Unslothモデル（Qwen3.6、Gemma4） をテストしたいニーズ
llama.cpp のWindowsビルドが面倒、既に多くのツールチェーンが混在
Windows は開発用途に不向きと感じており、ゲーム専用機として維持したい意向
GRUB の破損やUEFI管理の煩雑さを回避したい
USBブートは利便性・紛失リスク・誤消去の問題あり
既存の NAS を活用し、 PXE + iSCSI でネットワーク経由ブートを希望

PXE/iSCSIリモートブートの制約と前提

ネットワークドライブ へのDebianインストールはネイティブより速度劣化
モデルデータはローカルNVMeに配置し、OSパフォーマンスは重視しない
前提構成：
- Debian 13ベースサーバー （Netboot.xyz, tftpd, iSCSI Target, ZFS ZVol担当）
- Proxmox での運用
- Asus Router + Merlin firmware でDNSMasq利用

Netboot.xyzのインストールと設定

必要パッケージ のインストール
- apt install apache2 git ansible tftpd-hpa targetcli-fb
Netboot.xyz のクローンと編集
- /opt/netboot.xyz/user_overrides.ymlを編集し、site_nameとboot_domainをサーバーIPに
- テンプレートファイル（boot.cfg.j2, local-vars.ipxe.j2）を編集し、iSCSIブート対応
Ansible でインストール・展開
- ansible-playbook -i inventory site.yml
カスタムiPXEメニュー の作成
- /var/www/html/debian13-iscsi.ipxeにiSCSI接続情報記述
- /var/www/html/custom.ipxeでローカルカスタムメニュー追加
Debianインストーラーイメージ のダウンロード
- initrd.gzとlinuxを/var/www/html/assets/debian13/へ配置

TFTPサーバーの設定

/etc/default/tftpd-hpaでTFTP設定
- ディレクトリ・ユーザー・アドレス指定
Netboot.xyzバイナリ をTFTPディレクトリへコピー
- /srv/tftp/ipxeにkpxe/efiファイル配置
- サービス再起動：service tftpd-hpa restart

DNSMasq（DHCP）の設定

ルーターのdnsmasq設定 （例：Asus Merlin）
- /jffs/configs/dnsmasq.conf.addにPXE/iPXE両対応の設定を記述
  - BIOS用、UEFI用、iPXE用のdhcp-boot行を分岐指定
dnsmasq再起動 で反映

ZFS ZVOL作成

ZFSプール・ZVOLの作成
- zpool create tank /dev/disk/by-id/${DISK_ID}
- zfs create -V 32G tank/debian-disk-12700k
iSCSI以外の任意ディスクも利用可能

iSCSIターゲットの設定

targetcli でZVOLをiSCSIターゲットとしてエクスポート
- バックストア登録、ターゲット作成、TPG・ACL・認証情報設定
- LUNマッピング、ポータル確認、設定保存
認証情報 （ユーザー名・パスワード・相互認証）を必ず設定

Debianのインストール

PXE/iSCSI経由でDebianインストーラーを起動
- VM/実機どちらでも同様の手順で利用可能
iSCSIディスクをターゲットとしてDebianをインストール
- インストール後もGRUB等のブートローダーがリモートディスク上に配置されるため、Windows環境に影響を与えない

この手法により、 Windows環境を汚さず、 ネットワーク経由でLinux OSを柔軟に起動・運用 できる構成を実現可能。 ゲームPC と 開発環境 の完全分離が可能な点が大きなメリット。

Hackerたちの意見

いいね。ZFSをバックにしたネットワークルートファイルシステムが特に好きなんだ。OSをZFS上に置けるから、そのOSでZFSのサポートを気にしなくていいのがいいよね。（いつかOpenBSDをNFS経由でZFSのルートにして試してみたいな。LinuxかFreeBSDからね。）iSCSIとNBDについて、誰か意見ある？

└

直接の経験はないけど、調べたときの印象では、NBDはネットワークの中断に対してiSCSIほど信頼性がなかった。https://forums.gentoo.org/viewtopic.php?p=4895771&sid=f9b7ac... https://github.com/NetworkBlockDevice/nbd/issues/93 最新版でもそうかは分からないけど、試してみる価値はあるかもね。

└

https://smolbsd.org/ もいいかもね。

└

まあ、iSCSIは標準だから、非Linux OSでもサポートされる可能性が高いね。例えば、MS Windowsとか。何年か前に、そんな感じでWindows（7だったかな）クライアントをブートしたことがあるけど、SSDが安くなった時に面倒になってやめちゃった（ネットワークの制限でパフォーマンスが悪かったし）。

└

glusterを使うならNBDが必要だと思うけど、cephのことを考えてるかもしれない。

└

過去10年間、NBDをもっと速くて良いプロトコルにするためにたくさんの時間をかけてきたよ。パイプライン化されたリクエスト、トリムやゼロ化の完全サポート、複数接続での負荷分散、ちゃんとした仕様、新しいクライアントとサーバーの実装（libnbd, nbdkit）、標準のコマンドラインツール、すべての実装間の相互運用テスト、正式なURI仕様。NBDサーバーの設定はすごく簡単で、いろんなクライアントで接続する方法についてのドキュメントもたくさんあるよ（ここから始めてみて: https://gitlab.com/nbdkit/nbdkit https://libguestfs.org/nbdkit.1.html#SEE-ALSO）。残念ながら、この特定のケース（ディスクレスブート）では、dracutのサポートがまだイマイチで、いつか直さないといけないなと思ってる。

ここで言っておくべきことは、iSCSIは混雑したネットワークやインキャストトラフィックによるパケットロスに弱いってこと。これをうまく機能させるには、スイッチのQoS設定を変更して、iSCSIトラフィック用の優先VLANを作ることを考えてみて。

└

あるいは、ノースサウス/イーストウエストアーキテクチャにして、iSCSI専用の別ネットワークを作るって手もあるね。コントロールプレーンとデータプレーンの分離。

ヘッドレスやディスクレスのことは結構やってきたけど、最近はあまりやってないな。NASがギガビットイーサネットポートしかないから。カスケード接続して4Gbpsのダウンストリームは得られるけど、それでも辛い。最近、家を10Gbpsイーサネットにアップグレードしたんだけど、まだ一部の部屋がギガビットのままで、残念ながらそれがメインオフィスなんだ。今、その部屋の接続を整えようとしてるところ（まさに今、休憩中）。終わったとしても、10GbEでiSCSIドライブにアクセスするのはローカルのNVMeドライブより4～8倍遅くなるけど、前よりはずっと良くなるはず！理想を言えば、NASでVMを動かして素晴らしいパフォーマンスを得たいけど、それにはまたハードウェアのアップグレードが必要だね…

└

ほんとに、これがディスクレスってどういうことなんだろう？明らかにネットワーク越しにディスクやドライブにアクセスしてるのに。これってネットワークブートって呼ぶべきじゃない？

└

ChelsioのiSCSIアクセラレーターを使った適切なNICを使えば、iSCSIのパフォーマンスがかなり向上するよ。もう一つの選択肢は、RDMAを使ったMellanoxだね。TCP/IPで最適なパフォーマンスを得るにはCX4以上が必要だけど、安いCX3はIPoIBで素晴らしいよ。パケットのドロップや再送が多いなら、パケットバッファリング用にメモリがたくさんあるネットワークスイッチを使うのもiSCSIのパフォーマンスを上げる手段だね。これでインキャストの混雑も解消できる。特別にギガバイトのメモリを搭載したスイッチもあるよ。NVMe-oFはネットワークドライブ用のベストなプロトコルで、オーバーヘッドが最小限。適切な設定をすれば、Intel Optaneを使ってもローカルディスクと比べて遅延は10-20%しか増えないし、スループットもほぼ同じになるはず。

UEFIはある程度それを解決してくれるけど、UEFIエントリを手動で維持して、カーネルが更新されるたびに変更するのが面倒なんだ。…カーネルが更新されるたびにUEFIエントリを更新する必要はないよ。（CONFIG_EFI_STUBを使ってカーネルを置き換えて、UEFIブートエントリが指しているファイル名とは違う名前で新しいカーネルを置いたら、更新が必要かもしれないけど…それはちょっと珍しい設定だと思うし、EFIでブートしてるほとんどの人はGrubを使ってると思ってた。）

└

CONFIG_EFI_STUBを使っても、更新後にefibootmgrを自動で呼び出すフックがあるはずだよ。

└

それか、最新のカーネルを/vmlinuxや/initramfsにコピーするだけでもいい。

└

/efi/current.efiと/efi/old.efiの2つのエントリーがあるんだ。アップグレードするときは、currentをoldにコピーして、新しいカーネルを/bootからcurrentとしてコピーして再起動するよ。

SynologyやQNAPみたいなNASからブートするのは面白いセットアップになりそうだね。iSCSIはあんまり使ったことないけど、準備が大変そうでちょっと怖いな…。

└

「ターゲット」は動きが遅いから、一度覚えちゃえばずっと役立つよ。… それに、すごく楽しい。

└

iSCSIってわざと分かりにくくしてる感じがする。NBDに加えた改善の一つは、サーバーを簡単に指定できるようにするためにシンプルで標準化されたURIフォーマットを考えたことだよ。例えば、nbdinfo nbd://server、nbdcopy nbd://server:2001/、nbd+unix:///?socket=/tmp/localsock みたいにね。 https://github.com/NetworkBlockDevice/nbd/blob/master/doc/ur...

友達は友達にgrubを使わせない。rEFIndはめちゃくちゃシンプルだよ：EFIエントリが一つ、EFIパーティションにテキスト設定ファイルが一つ、カーネルが更新されても何も変える必要なし。テンプレートや動くパーツの山があって、謎に壊れてgrubの「リカバリー」シェルに突っ込まれることもないからね。

└

systemd-bootもあって、最近人気が出てきてるみたいだね。 https://systemd.io/BOOT/

└

シンプルなブートシナリオならsystemd-bootが一番だね。大好き！ grubは本当にごちゃごちゃしてるって同意するよ。

└

それか、BLSを使っているsystemd-bootを使えば、設定ファイルがいらないよ。

└

rEFIndはセキュアブートとメジャードブートに対応してるのかな？ systemdはあんまり好きじゃないけど、systemd-bootは手間いらずでこれを実現してくれるし、実際に便利なんだよね。

└

rEFIndは本当にシンプルだよ。正直、HackintoshやBSDでしか使ったことないから、なんで使いたいのか分からないけど… でも、長い鼻を持った大きな毛むくじゃらのやつが邪魔で、投稿するのが難しいんだ。これらはUEFIでしか動かないし、UEFIは好きじゃない。ほとんど毎日使ってる機器にはUEFIが全くないから。GRUBはBIOSでもUEFIでもx86でもArmでも、なんでも動くよ。LinuxやBSD、Haikuなど、何でもブートできる。だからGRUBが勝つんだ。GRUBは敵対的で不親切で、理解しにくいから嫌いだけど… でも、他の選択肢よりも多くの機器でちゃんと動くんだよね。

└

でも、暗号化された/bootには対応してるのかな？

└

それめっちゃ好きだった、笑ったわ。「友達は友達にgrubを使わせない」ってね。rEFIndが一番良さそうだなって思った。

└

rEFIndを使ってるのは、GRUBやsystemd-bootとは違ってNVMe EFIドライバーを読み込めるからなんだ。rEFIndは本当のUEFIブートローダーだと思う。Fedoraはカーネルをインストールしたり削除したりするときに設定を更新しないみたいだから、rEFIndはsystemd-bootを動かすためだけに使ってる。Fedoraでは結構サポートされてるしね。rEFIndにカーネルを探させたり、kernel-installを修正・調整することもできるけど、壊れてないものを直す必要はないよね？ちなみに、rEFIndがデフォルトで自動的にいくつかのことをやっちゃうのが好きじゃないし、ブートメニューがちょっとごちゃごちゃするのも気になる。少し設定を調整する必要があったけど、少なくともデフォルトを上書きしたりメニューエントリを追加したりできる別の設定ファイルを含められるから、完全にシンプルとは言えないかな。もっとミニマリストなsystemd-bootの方が好きなんだ。 [1]: https://www.freedesktop.org/software/systemd/man/latest/kern...

└

rEFIndって、どこかのディスクにある.isoファイルをブートできるの？Grubはできるけど！

└

それならもっといいのがあるよ: https://zfsbootmenu.org/

コンセプトは好きだけど、プレゼンテーションや理由付けはあんまり好きじゃないな。でも、このアイデアや似たようなものは前にも出てるよね…「XenとAlpine Linuxを使った手間いらずのディスクレス仮想マシン」 https://jonnytyers.wordpress.com/2016/08/16/hassle-free-disk... 「ディスクレス仮想マシン(KVM)の作り方」 https://github.com/lispydev/diskless-kvm それから、超簡単なPXEサーバーが欲しいなら… https://www.iventoy.com/en/index.html

Sun Solarisの頃（あとPowerPC Mac）に使ってたOpen Firmware（IEEE 1275）の「boot net」が今でも恋しいな。* https://en.wikipedia.org/wiki/Open_Firmware

この投稿、思ったより注目を集めたな。家庭用ハードウェアで動かしたものをシェアしたかったんだ。自分がちょっと慣れてるソフトウェアを使ってね。これが実装の唯一の方法ではないし、もっと良い方法があると思う。フィードバックありがとう、編集して代替スタックやiSCSIのネットワークのこだわりについてももっとポイントを追加するよ。

10年前にUbuntu LTSPを使って似たようなことをやったよ。ディスクレスのオフィス用コンピュータを何台も使って、1台のサーバーからブートして全部RAMで動かしてた。アップデートは？ベースイメージを再構築して、端末を再起動するだけ。オフィス用のWindowsのセットアップよりずっといいよ、同じような端末がたくさん必要だからね。

ハクソク