Proxmox上のOrico/JMicron JMS56xエンクロージャー環境では、USBデバイスがZimaOSゲストに到達し、カーネルもブリッジを検出しましたが、USBデバイスが切断される前にsdXブロックデバイスは現れませんでした。ユーザーが報告した、Proxmoxホストから個々のディスクをパススルーする方法が、実際に機能した回避策でした。
あるコミュニティの返信では、原因としてusb_storage/uasモジュールの不足が挙げられていました。ただし、これは検証済みの事実ではなく仮説として扱うべきです。投稿されたZimaOSのログ自体にusb-storage ... USB Mass Storage device detectedと記録され、SCSIホストも作成されているためです。
元のログから実際に確認できること
Proxmoxはベンダー/製品ID 152d:0565をVMに正常に接続しました。その後ZimaOSはJMS56xブリッジを検出し、USBストレージ用のSCSIホストを起動しましたが、想定されるダイレクトアクセスディスクの行やブロックデバイスは生成されませんでした。
同じエンクロージャーは、同じProxmoxホスト上のDebian 13 VMでは動作しました。このことから、ZimaOSゲスト環境が互換性上の有力な原因候補であることは示唆されますが、どのカーネルオプション、クワーク、またはブリッジの動作が原因なのかまでは、それだけでは特定できません。
modprobeの失敗だけでは原因を特定できない理由
modprobe usb_storageコマンドが失敗しても、実行中のカーネルがすでにusb-storageによる動作をログに記録している場合、USBストレージのサポートが存在しないことの証明にはなりません。ドライバーは、ロード可能なモジュールではなく、カーネルに組み込まれている場合もあります。
そのため、IceWhaleが現在のリリースにおける正確なドライバー構成を確認しない限り、フォーラム上の説明をZimaOS公式のカーネル制限として提示しないでください。
より安定したパススルー境界を使用する
Proxmoxでは、Proxmox VE管理ガイドにおいて、ベンダー/製品IDまたはバス/ポートによるホストUSBパススルーを説明しています。USBブリッジ全体をZimaOS内で正常に初期化できない場合は、別の層でストレージをパススルーする方法が実用的な代替策になります。
元の投稿者はすでに、ディスクをProxmoxホストに接続し、ホストのディスクをZimaOSにパススルーすることで動作することを確認しています。重要なデータについては、まず1台のディスクでテストし、再起動後も識別子が安定していることを確認してください。
ZimaOS 1.7.1でこのJMS56xの問題が解決したと決めつけない
ZimaOS 1.7.1の変更履歴には、再起動後に一部のUSB関連タスクが失われる問題の修正が記載されています。ただし、JMS56x、UAS、USBマスストレージのパススルー、またはProxmoxブリッジの互換性については触れられていません。
仮想化環境にZimaOSをインストールする場合は、ストレージのパススルー構成を変更する前に、ZimaOSインストール・トラブルシューティングガイドも参照するとよいでしょう。
結論
確認されている症状は、「USBブリッジは列挙されるが、ディスクがブロックデバイスにならない」というものです。ホストディスクのパススルーによって回避できました。スレッド内では正確なカーネルレベルの原因は証明されていないため、現在のZimaOSリリースでトラブルシューティングする際も、その不確実性を維持してください。
