ZVMゲストは有効なLANアドレスを取得していても、ZimaOSホスト自体で動作しているサービスに接続できない場合があります。このスレッドの中心的な問題はこれでした。VMをeth0へのブリッジに設定すると、ゲストはLANに参加できましたが、ホストへのルートがないと報告されました。Zima-Giorgioは、ZimaOSの共有に接続することが目的なら、VMをNATに切り替えるよう推奨しました。
この情報からは、「ネットワークルート」と「SMB権限」が別々の問題であることも分かります。後のユーザーの一人はNATに切り替えてログインダイアログまで到達できましたが、複数のアカウントでRAID共有にはアクセスできませんでした。この認証・ストレージの問題を、ブリッジモードにおけるホスト分離の問題と混同しないでください。
ブリッジモードではVMが通常のLAN到達性を得られた
元のユーザーは、VMをローカルネットワーク上の別のデバイスのように動作させたかったため、「eth0へのブリッジ」を選択しました。このモードでは、VMはLANアドレスを取得し、LAN上の他のシステムと通信できました。
不足していた経路は、VMとZimaOSホスト間の通信に限られていました。
Zima-GiorgioはホストへのアクセスにNATを推奨した
IceWhaleのZima-Giorgioは、VMをシャットダウンし、ネットワーク設定をブリッジからNATに変更するようユーザーに伝えました。その後の返信では、NATならホストにアクセスでき、ブリッジなら他のLANデバイスにアクセスできるというトレードオフだと、自身の経験を説明しました。
これは2025年の元スレッドにおける公式サポートの案内であり、あらゆるlibvirtトポロジーに当てはまる一般論ではありません。
後のコミュニティ報告もmacvtapのホスト分離と一致した
2026年5月から6月にかけて、別のコミュニティスレッドでも同じパターンが報告されました。ブリッジ接続したVMは通常のLAN IPアドレスを取得し、他のLANデバイスには接続できましたが、ZimaOSホストにはARPも接続もできませんでした。NATに切り替えると、ホストへの接続が直ちに回復しました。
ユーザーたちは、ZVMの「eth0へのブリッジ」経路がmacvtapで実装されているのではないかと推測しました。macvtapのホスト分離動作はよく知られています。ただし、公開スレッドにはIceWhaleによる正確なバックエンドの確認が含まれていないため、macvtapは有力なコミュニティ上の説明にとどめ、公式の実装情報として扱うべきではありません。
SMBのログイン問題は別の層にある
参加者の一人はNATに切り替え、ようやくZimaCubeのログインダイアログに到達できましたが、SMBアカウントの動作には依然として一貫性がありませんでした。メインアカウントでは一部のホストパスを参照できたもののRAIDへのアクセスに失敗し、他のアカウントでは権限エラーが返されました。
基本的なIP到達性が確保できたら、SMB共有のアカウントと権限は別途トラブルシューティングしてください。
現在のZimaOSドキュメントでは、ユーザーごとのSamba共有と、読み取りまたは読み取り・書き込み権限が説明されています。VMからアクセスを試す際に、サーバーには到達できるものの認証またはアクセスに失敗する場合は、現在のZimaOS Sambaマルチユーザー権限モデルを使用してください。
Ubuntuのファイル共有とリモートログインの項目は同じプロトコルではない
元のユーザーは、Ubuntuに「ZimaCube（ファイル共有）」と「ZimaCube（リモートログイン）」が表示されることに気付きました。パスワードマネージャーには、後者についてsftp://接続も表示されていました。
SSH経由のSFTPとSMBは異なるサービスです。SFTPへのログインに成功しても、SMBの権限が正しいことの証明にはなりません。また、SMB共有はSSHの項目ではなく、SMB URLまたはネットワーク共有ブラウザーを使ってテストしてください。
コミュニティのユーザーがブリッジモード用に静的ルートの回避策を構築した
別の参加者はVMをブリッジ接続したまま、VMとホストの間のルーターとして3台目のDebianサーバーを使用し、両方のエンドポイントに静的ルートを追加しました。動作したものの、結果を「見栄えがよくない」と説明しています。
これらのLinuxルーティングコマンドはコミュニティによる実験であり、IceWhaleが推奨するZVMの設計ではありません。追加したルーターはスループットのボトルネックとなり、障害点も一つ増えます。
VMの実際の役割に基づいてネットワークを選択する
- VMが主にZimaOS上のサービスや共有にアクセスする必要がある場合：まずNATを試すのが、元のサポート情報に基づく方法です。
- VMが主に独立したLANデバイスとして動作する必要がある場合：ブリッジにより、通常のLANアドレスを取得できます。
- VMがホストとLANの両方に到達する必要がある場合：現在のZVMリリースで慎重にテストしてください。過去の情報では、これが未解決の問題でした。
現在のZimaOSネットワーク設定には、ZVM向けのbr0ワークフローが記載されていない
現在公開されているZimaOSのネットワークドキュメントでは、物理インターフェース、DHCPまたは手動IP設定、リモートアクセスについて説明されています。ZVMのホスト分離動作を回避するためにカスタムホストブリッジを作成する、サポート対象の手順は公開されていません。
ZVM向けにサポート対象外のホストネットワーク変更を行うため、ホストのルートやNetworkManagerのファイルを手動で編集する前に、現在のZimaOSネットワークモデルを確認してください。
ZVMのホストアクセスに関するよくある質問
NATで元のVMはZimaOSホストに接続できましたか？
はい。NATに変更すると、ホストへのルートがない問題が解消されたとユーザーが報告しています。
NATでSMB権限も自動的に修正されましたか？
いいえ。あるユーザーはログインダイアログに到達できましたが、共有権限に関する別の問題は残りました。
3台目のサーバーを使ったルーティングの回避策は公式のものでしたか？
いいえ。ブリッジモードを維持したいユーザー向けのコミュニティによる回避策でした。
