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을 사용해 구현되었을 가능성을 제기했습니다. 공개 스레드에는 정확한 백엔드에 대한 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을 브리지 상태로 유지하고 세 번째 Debian 서버를 VM과 호스트 사이의 라우터로 사용한 뒤, 양쪽 엔드포인트에 정적 경로를 추가했습니다. 작동하기는 했지만 결과가 “깔끔하지 않다”고 평가했습니다.
이러한 Linux 라우팅 명령은 커뮤니티의 실험적 방법이며, IceWhale이 권장한 ZVM 설계가 아닙니다. 추가 라우터는 처리량 병목이 될 뿐 아니라 장애 지점도 하나 더 추가합니다.
VM의 실제 역할에 따라 네트워크를 선택하세요
- VM이 주로 ZimaOS 호스팅 서비스 또는 공유에 연결해야 하는 경우: NAT를 먼저 테스트하는 것이 이 자료에서 지원하는 방법입니다.
- VM이 주로 별도의 LAN 장치처럼 동작해야 하는 경우: 브리지를 사용하면 일반적인 LAN 주소를 제공할 수 있습니다.
- VM에 호스트와 LAN 모두에 대한 연결성이 필요한 경우: 현재 ZVM 릴리스를 신중하게 테스트하세요. 과거 자료에서는 이것이 해결되지 않은 격차로 나타났습니다.
현재 ZimaOS 네트워크 설정 문서에는 ZVM용 br0 워크플로가 설명되어 있지 않습니다
현재 공개된 ZimaOS 네트워킹 문서에서는 물리 인터페이스, DHCP 또는 수동 IP 구성, 원격 액세스를 다룹니다. ZVM의 호스트 격리 동작을 우회하기 위해 특별히 사용자 지정 호스트 브리지를 만드는 지원 절차는 게시되어 있지 않습니다.
ZVM을 위해 지원되지 않는 호스트 네트워크 변경을 수행하기 전에 현재 ZimaOS 네트워킹 모델을 확인하세요.
ZVM 호스트 액세스 FAQ
원본 글의 VM은 NAT를 통해 ZimaOS 호스트에 연결할 수 있었나요?
예. 사용자들은 NAT로 변경하자 호스트로 가는 경로가 없던 문제가 해결되었다고 보고했습니다.
NAT가 SMB 권한 문제도 자동으로 해결했나요?
아니요. 한 사용자는 로그인 대화 상자에 접근할 수 있었지만, 공유 권한 문제는 별도로 계속 발생했습니다.
세 번째 서버를 이용한 라우팅 우회 방법은 공식 방법이었나요?
아니요. 브리지 모드를 유지하려는 사용자를 위한 커뮤니티 우회 방법이었습니다.
