이 2025년 9월 보고서는 현재의 “ZVM이 작동하지 않는다”는 결론이 아니라, 당시 베타 버전에 한정된 역사적 ZVM 오류로 보아야 합니다. 사용자는 ZimaOS 1.4.4-beta1을 실행 중이었고 VM 시작 시 client socket is closed라는 내부 메시지와 함께 반복적으로 실패했습니다. Zima-Giorgio는 동일한 베타 버전에서 Ubuntu VM을 테스트한 결과 정상적으로 실행되었다고 밝혔으므로, 이 문제는 모든 1.4.4-beta1 설치에서 보편적으로 발생한 것은 아니었습니다.
이 글에서 유용한 부분은 진단 범위를 좁혀 간 과정입니다. KVM은 로드되어 있었고, 기본 libvirt 네트워크와 스토리지 풀은 활성 상태였으며, libvirt 설정을 초기화해도 도움이 되지 않았습니다. 이후 로그에는 다음이 표시되었습니다. virtqemud libvirt 네트워크 소켓에 연결하지 못한 후 비활성화되었습니다.
libvirt-guests 재시작은 올바른 계층의 조치가 아니었음
원래 사용자는 먼저 다음 서비스를 재시작했습니다. libvirt-guests.service한 커뮤니티 응답자는 이 서비스가 주로 호스트 종료 시 게스트 저장 및 복원 동작을 처리하며, VM을 실행하는 핵심 QEMU/libvirt 데몬은 아니라고 지적했습니다.
따라서 해당 서비스를 성공적으로 재시작했다고 해서 VM 스택이 정상이라는 의미는 아니었습니다.
KVM 하드웨어 가속이 활성화되어 있었음
사용자는 로드된 모듈을 확인했고 두 모듈이 모두 있음을 발견했습니다. kvm 및 kvm_intel이는 흔한 원인 중 하나인 커널 수준에서 가상화 지원을 완전히 사용할 수 없는 상태를 배제했습니다.
기본 네트워크와 스토리지 풀이 활성 상태였음
이 글에서는 libvirt의 기본 네트워크와 스토리지 풀도 확인했습니다. 둘 다 활성 상태이며 액세스할 수 있는 것으로 보고되었습니다.
이로 인해 VM 스토리지 누락이나 비활성 NAT 네트워크가 주된 원인일 가능성은 낮아졌습니다.
전체 libvirt 설정 초기화로도 해결되지 않음
원래 게시자는 다음 경로의 설정을 삭제했습니다. /etc/libvirt 및 /var/lib/libvirt 그래도 오류가 재현되었습니다. 이는 파괴적인 진단 단계이므로 현재의 첫 번째 해결 방법으로 권장해서는 안 됩니다.
최신 운영 환경에서는 libvirt 상태를 변경하기 전에 VM 정의와 디스크 이미지를 백업하세요.
이후 로그에서 virtqemud와 네트워크 소켓이 지목됨
이후 사용자는 더 유용한 오류를 게시했습니다: virtqemud 소켓에 연결하지 못했습니다 /var/run/libvirt/...그 후 서비스가 비활성화되었습니다. 따라서 UI에 표시된 클라이언트 소켓 닫힘 메시지는 백엔드 데몬 문제로 인한 연쇄적인 증상일 가능성이 높았습니다.
“정상적으로 종료됨”으로 표시되는 데몬도 애플리케이션을 중단시킬 수 있습니다
여러 libvirt 데몬은 소켓 활성화 방식으로 실행되며 유휴 상태가 되면 중지될 수 있으므로 “inactive”만으로는 오류의 증거가 되지 않습니다. 그러나 이 사례에서는 명시적인 소켓 연결 실패와 VM 종료 로그가 백엔드 상호 작용에 문제가 있을 가능성을 보여 주었습니다.
systemd 상태는 단일 상태 줄만으로 판단하지 말고 실제 libvirt/QEMU 오류와 함께 해석하세요.
IceWhale은 테스트 환경에서 오류를 재현하지 못했습니다
Zima-Giorgio는 1.4.4-beta1에서 Ubuntu VM이 정상적으로 실행되었다고 말하며 OS 유형과 스크린샷 또는 동영상을 요청했습니다. 이는 중요한 공식적 기준입니다. 해당 자료는 실제 사용자 오류를 보여 주지만 베타 전체에서 확인된 장애를 보여 주지는 않습니다.
사용자는 이를 GitHub 베타 버그로 제기했습니다
게시자는 포럼에서 파일 업로드가 어려웠기 때문에 상세 로그와 동영상을 IceWhale의 GitHub 트래커로 옮겼습니다. 첨부된 자료는 정적인 포럼 스크린샷이 아니라 동영상이었습니다.
공개 포럼 스레드에는 단일한 확인된 근본 원인을 밝힌 릴리스 노트나 최종 패치가 없습니다.
현재 ZimaOS에 1.4.4-beta1 서비스 수술을 적용하지 마세요
현재 ZimaOS는 이 베타 버전보다 훨씬 발전했습니다. libvirt 패키징, ZVM UI, 이미지 지원, systemd 서비스 동작은 모두 다를 수 있습니다.
현재 유사한 오류가 발생하면 시스템 파일을 변경하기 전에 VM 오류, 현재 ZimaOS 버전, KVM 상태, libvirt 네트워크 및 스토리지 상태, QEMU 로그를 수집하세요.
사용자가 더 나은 증거를 수집하면서 오류 양상이 바뀌었습니다
초기에는 서비스 재시작으로도 해결되지 않았기 때문에 ZVM 베타에 더 심각한 버그가 있다고 단순히 추정했습니다. 다음 조사에서는 KVM이 존재하고 기본 네트워크와 스토리지가 정상임을 확인했습니다. 그 이후에야 내부의 소켓 오류가 virtqemud 표시됩니다.
이 진행 순서는 가상화 문제 해결의 좋은 모델입니다. 일반적인 UI 오류가 발생했다고 바로 하이퍼바이저를 다시 설치하지 마세요. 하드웨어 가속, 스토리지, 네트워크, 서비스 계층을 순서대로 배제하세요.
virtqemud는 모듈식 libvirt 스택의 나머지 구성 요소에 의존합니다
기록된 오류는 libvirt 네트워크 소켓을 참조했습니다. 최신 모듈식 libvirt에서는 QEMU 관리, 네트워크 관리, 로깅 및 기타 기능이 별도의 데몬과 소켓에 분리되어 실행될 수 있습니다. 따라서 QEMU 데몬이 실행 중이어도 필요한 네트워크 데몬과 통신하지 못할 수 있습니다.
이는 KVM과 스토리지 풀이 정상적으로 보이는데도 VM이 실패할 수 있었던 이유를 설명하는 데 도움이 됩니다.
QEMU 로그에는 게스트가 종료된 기록이 있었습니다
사용자의 QEMU 로그에는 게스트 프로세스가 다음에서 시그널 15로 반복 종료된 기록이 있었습니다. virtqemud이는 게스트가 불량 Windows 또는 Linux ISO 때문에 충돌한 것이 아니라 가상화 제어 스택에 의해 종료되고 있었다는 해석을 뒷받침합니다.
사용자는 여러 ISO 이미지도 테스트했으며 동일한 동작을 확인했습니다. 이는 “설치 미디어 불량”이라는 설명을 더욱 약화합니다.
베타 회귀 문제는 파괴적인 복구를 수행하기 전에 안정 버전과 비교해야 합니다
커뮤니티 답변에서는 VM이 즉시 필요하다면 안정 채널로 롤백해 보라고 제안했습니다. 이는 베타 버전에만 발생하는 장애에 대한 합리적인 진단 기준입니다. 동일한 VM과 하드웨어가 안정 버전에서 작동한다면 베타 버전이 가장 강력한 변경 변수이기 때문입니다.
원문 스레드에는 원 게시자가 최종적으로 롤백했음을 확인하는 내용이 없으므로, 이는 검증된 원문 해결 방법이 아니라 진단 전략으로 남아 있습니다.
현재 ZVM 장애에서는 최초 백엔드 오류를 보존하세요
“클라이언트 소켓이 닫혔습니다”와 같은 UI 메시지는 의미 있는 백엔드 이벤트가 발생한 후에 나타나는 경우가 많습니다. 시작을 클릭한 정확한 순간의 시스템 및 QEMU 로그를 수집하고, 최종 상태 메시지만이 아니라 가장 이른 오류를 보존하세요.
이는 하위 증상을 근본 원인으로 잘못 판단할 위험을 줄여 줍니다.
ZVM 베타 관련 과거 FAQ
원래 사례에서 KVM이 누락되어 있었나요?
아니요. 사용자는 KVM 모듈이 로드되어 있다고 확인했습니다.
libvirt 구성을 초기화하면 문제가 해결되었나요?
아니요.
모든 1.4.4-beta1 시스템에서 문제가 확인되었나요?
아니요. Zima-Giorgio는 동일한 베타 버전에서 Ubuntu 테스트 VM이 정상적으로 실행되었다고 말했습니다.
가장 강력한 백엔드 단서는 무엇이었나요?
virtqemud 비활성화 전에 libvirt 네트워크 소켓 연결에 실패한 기록이 있습니다.
