世界を動かす技術を、日本語で。

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

2026年5月7日原文(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_nameboot_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.gzlinux/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を使ってると思ってた。)

Hacker Newsで議論の続きを見る