합성 로그 기준으로, QEMU에 정상 종료되지 않은 이전 콘솔 연결(VNC) 세션이 남아 새 연결을 막는 실행 환경 문제일 가능성이 가장 높습니다. 가상머신 안의 운영체제와 서비스에는 영향을 주지 않을 수 있습니다. 서비스 중단을 최소화하려면 상태를 먼저 확인한 뒤 Mold에서 라이브 마이그레이션을 수행하는 것이 우선입니다.
먼저 다음 해결 방법을 적용해 보세요.
- 가장 우선할 복구 방법은 Mold의 라이브 마이그레이션입니다. 실행하기 전에 서버 관리자에게 현재 VM이 실행 중인 KVM 호스트에서 다음 읽기 전용 검사를 요청하십시오.
<VM>에는 libvirt 가상머신 이름을 넣습니다. 정상 기준은 domstate가 실행 상태이고, VNC URI와 graphics 설정이 존재하며, query-vnc에서 서버가 활성화되고 host와 service가 표시되는 것입니다. 오래된 client가 계속 표시되면 잔존 세션 가능성이 더 높습니다.
sudo virsh domstate <VM>
sudo virsh domdisplay <VM> --type vnc
sudo virsh qemu-monitor-command <VM> --pretty '{"execute":"query-vnc"}'
sudo virsh dumpxml <VM> | sed -n '/<graphics/,/<\/graphics>/p'
- 대상 호스트의 QEMU 호환성, 네트워크, 저장소 조건, 여유 자원 및 진행 중 작업을 확인한 후 Mold에서 라이브 마이그레이션을 실행하십시오. 완료 기준은 VM이 대상 호스트에서 실행 상태를 유지하고 콘솔이 ‘연결중’을 벗어나는 것입니다. 진행 상황이 필요하면 VM이 있는 호스트에서 다음 명령으로 확인할 수 있습니다. Mold 관리 상태와 어긋날 수 있으므로 직접
virsh migrate를 실행하지 마십시오.
sudo virsh domjobinfo <VM>
- 라이브 마이그레이션을 지원하지 않거나 조건을 충족하지 못하면 Mold에서 VM을 정지한 뒤 다시 시작하십시오. 가상머신 실행 프로그램(QEMU)와 VNC 소켓이 초기화되지만, 이 방법은 게스트 서비스 중단을 수반합니다.
- 조치 후 첫 번째 검사를 다시 실행하십시오.
query-vnc에서 이전 client가 사라지고 새 콘솔이 정상 연결되면 복구된 것입니다.
- 마이그레이션 또는 정지 후 시작으로 해결되지 않으면 VM 호스트에서 최근 libvirt/QEMU 로그를 확인하십시오.
sudo journalctl -u libvirtd -u virtqemud --since '-15 min' --no-pager | grep -Ei 'vnc|console|websocket|qemu|error'
- 같은 호스트의 여러 VM에서 동시에 발생하거나 위 초기화 뒤에도 계속되면 그때 Console Proxy 시스템 VM, 브라우저 실시간 연결, DNS 및 방화벽 경로를 점검하십시오.
첨부해 주신 자료에서는 다음 내용을 확인했습니다.
- 콘솔 세션 요청 뒤 브라우저 실시간 연결이 연결중 상태에 머물렀지만 가상머신 안의 운영체제 heartbeat는 정상입니다.
- QEMU VNC 리스너는 활성 상태이지만 이전 VNC 클라이언트 세션이 정상 종료되지 않았습니다.
현재 자료로는 ABLESTACK 제품 코드의 오류라기보다 가상화 프로그램이 일시적으로 정상 상태를 잃은 문제에 가깝습니다.
이 방법을 먼저 권장하는 이유는 다음과 같습니다.
- QEMU에 정상 종료되지 않은 이전 VNC 클라이언트 세션이 남아 있음
- 콘솔 프록시 또는 브라우저 실시간 연결·DNS·방화벽 경로 이상
위 조치로 해결되지 않으면 아래 결과를 알려주세요. 이미 제공한 내용은 다시 보내지 않으셔도 됩니다.
- 위 조치로 해결되지 않을 때만, 네 가지 읽기 전용 명령의 조치 전·후 전체 출력과 제시한 다음 명령 명령 결과가 필요합니다. 비밀번호나 토큰은 제외해야 합니다.
journalctl
