NFSでカーネルモジュールをホストすることを拒否します。 （モジュールだけでなく、お客様はモジュールの保管場所の変更に正確に気付くでしょう）。
どのように機能するはずだったのか
クライアント仮想マシンは、コアを使用してロードされます（つまり、カーネルコードは仮想マシンの外部に保存されます）。 カーネルにはプロセス内のモジュールが必要です。 / lib / modulesはNFSによってマウントされ、カーネル自体がどのディレクトリからどのモジュールをロードするかを決定します。それらを簡単に更新し、クライアントが簡単にアクセスできます。判明したように
まず、NFSボールはネットワークの初期化よりも後（これは明らかです）にマウントされ、fstabの他のすべての行をマウントした後です。 さらにクール-debian / ubuntuファミリーでは、デフォルトで非同期にマウントされるため、rc.localが実行されている状態で競合状態になります。結論：インターフェイスの事前スクリプトは期待どおりに動作せず、fstabからの非標準のファイルシステムは期待どおりにマウントされません。 さらに、NFSは最も信頼性の高いサービスではありません（特にバグ＃538000を考慮すると）、つまり、不便です。
この問題を解決する方法
モジュールはISO'shokuに配置され、すべての仮想マシンに個別のディスク/ dev / xvdpとして接続されています。 モジュールは、ルート（「/」）をマウントした直後にマウントされ、後続のすべての操作（事前スクリプト、非標準のファイルシステムなど）を簡単に実行できます。マウント行（fstab）は誰にとっても同じように見えます。
/ dev / xvdp / lib / modules iso9660 ro 0 0
ちなみに、このディスクは顧客から支払われません。
なぜ読み取り専用なのですか？
まず、すでに述べたように、それはすべてのものです。 たとえば、隣人に特別なバージョンのiptablesを添付して欲しくありません。 第二に、モジュール（カーネルなど）は制御システムによって制御されます。 近いうちに...まあ、近い将来、使用するコアを選択する機能が追加されますが、コアはリストから追加されます。 その理由は単純です-xenの下にはあまり安定していないカーネルがたくさんあります。 たとえば、debianはこれに苦しんでいます。 ああ。 さらに、バグの一部はすぐには表示されません。選択しなかったコアの安定性に関する質問に答える必要を避けたいと思いました。 Xenの準仮想化は、多くの操作（移行など）におけるカーネルの協力を意味します。プロセスの途中でこの協力を放棄すると、マシンが動作不能になる可能性があります。 そのため、カーネルは、考えられるすべてのユースケースに対して非常に退屈なテストを行った後にのみクラウドに移行します。モジュールをロードできますか？
はい、できます。 / lib / modulesは読み取り専用でマウントされているにもかかわらず、insmodを使用してどこからでもモジュールをロードできます。 唯一の「しかし」、時々更新するカーネル、この場合、提供するモジュールも更新されます。 そして、自分でモジュールを再構築する必要があります。 幸いなことに、更新は常に明らかであり、「誤って破損」することはありません。なぜiso9660なのか？
これは、CD（およびISOイメージ）で使用されるファイルシステムです。最も自然なのは読み取り専用モードです。 ext3を使用した場合は、rwで再マウントするように誘惑されます（これは実行できず、多くのエラーが表示されていました）。 2番目の理由-インストール中にOSインストーラーはiso9660を無視します（そこでパーティションテーブルを作成しようとする人はいません）。NFSからISOに移行する方法
簡単なスクリプト：sed -i /109.234.152.2/d / etc / fstab echo "/ dev / xvdp / lib / modules iso9660 ro 0 0" >> / etc / fstab umount / lib / modules マウント/ lib /モジュール
再起動は必要ありません。
新しいマシンでは、モジュールは必要に応じて正確にマウントされます。
もちろん、先に進む必要はありません。必要に応じて（古いモジュールシステムを持つ最後のマシンまで）NFSで現在の構成を維持します。 新しいシステムに切り替えた人は、NFSの痕跡を安全に切り取ることができます-もはや必要ありません。