仮想マシン内のZFS
仮想マシン内でZFSを使用する必要がありますか？既存の情報（特に このスレッド については、以下で引用します）によると、特定の手段（VT-dの使用など）が提供されていない限り、それは良い考えではありません。伝えられるところによると、基本的な問題は、実際にはまだ書き込まれていないのに、ハイパーバイザーが書き込まれるブロックを報告する可能性があることです。伝えられるところによると、ZFSは他のファイルシステムと比較してそのような不一致に特に敏感です：
なぜそれがそんなに悪いのかという詳細は、それがfsckのない設計に関連している。
その議論では、次のことも認められました。
「データの前に書き込まれたポインター」が「ポインターは書き込まれたがデータがない」に変わる唯一のシナリオは、私が想像できる限り、依然としてOSまたはハイパーバイザーのいずれかのクラッシュのイベントです。
しかし、そのようなクラッシュが発生した場合の最悪の結果は何ですか？
- クラッシュの前後に書き込まれたファイルの破損または損失？
- データセット内の他のファイルの破損または損失？
- クラッシュの前後に変更されていなかったデータセット内のファイルの破損または損失（クラッシュのかなり前に作成されたスナップショットなど）
スクラブで検出できないサイレント破損が発生する可能性はありますか？
VM内のZFSにデータが書き込まれている間、VirtualBoxを使用して[閉じる]/[電源オフ]を選択することで、クラッシュをシミュレートしようとしました。 20回ほどやりましたが、問題はありませんでした。おそらく、このテスト方法は適切ではありません。これを試す良い方法はありますか？
基本的に、すべての最新のハイパーバイザー（VMWare、Xen、KVM、HyperV、VirtualBoxでも）はバリアの受け渡しをサポートしています。aVMが明示的に何かをディスクにフラッシュすると（バリア/ FUAを発行することにより）、ハイパーバイザーはホストへの障壁。ゲストOSによって実行される同じフラッシュを強制します。言い換えると、重要な/永続的な書き込みの破損は予想されません（メタデータを更新するためにファイルシステム自体が使用するものとして）。
ほとんどのハイパーバイザーはフラッシュを無視するように設定できますが、これはanyファイルシステムを危険にさらす可能性があります-XFS、EXT4などはZFSと同じくらい深刻な破損にさらされます。
主な質問に戻ります。ゲストOS内でZFSを使用することは完全に安全であり、私は同様の設定を直接経験しています。これにより、ゲストは圧縮、スナップショット、送受信などの高度な機能を使用できるようになります。ただし、これによりゲストのパフォーマンスが多少低下する可能性があります（ZFSはベンチマークを獲得したファイルシステムになるように設計されていません）。さらに、多くのSANはディスクイメージレベルでまったく同じ機能を実装しているため、ダブルCoWによるパフォーマンスへの影響がゲストレベルでの追加の柔軟性に見合うかどうかを評価する必要があります。
上記の理由から、私は通常、仮想マシン自体の内部でXFSまたはEXT4を使用しながら、ディスクイメージ/ハイパーバイザーレベルでZFSを使用します。ただし、基盤となるSAN /ストレージ（およびそのスナップショット/圧縮/レプリケーションポリシー）が見えないシナリオでは、ゲストレベルでZFSを使用することがあります。
これらの場合、追加された機能は、たとえば単純なXFSセットアップと比較して、パフォーマンスへの影響を補償する以上のものです。また、安定性/耐久性の問題はまったくありません。
注意事項：VT-dは、RAWディスク（または他のハードウェアデバイス）をゲスト自体に渡すことを計画している場合にのみ役立ちます。ファイルまたはボリュームベースの仮想ディスクを使用している場合は、VT-dを使用していません。