다시 올려주신 untitled.txt와 이미지 12장을 함께 확인했습니다. TXT에서 확인되는 실제 VM 저장소의 FC 경로 장애와 Windows에서 확인되는 비정상 종료·E: 파일시스템 오류를 함께 다뤄야 합니다. 앞선 자동 답변의 용량 해석부터 바로잡겠습니다. 디스크 관리 화면의 E: 약 90%, D: 약 98%는 사용률이 아니라 여유 공간 비율입니다. E:는 약 500GB 중 449.73GB, D:는 150GB 중 147.04GB가 여유로 보이므로, 이 화면을 근거로 디스크 증설이나 공간 정리를 해결책으로 제시하는 것은 맞지 않습니다.
untitled.txt에서는 다음 연결을 확인했습니다.
/mnt/glue-gfs
→ /dev/mapper/vg_glue-lv_glue (GFS2)
→ mpatha
→ sde / sdm / sdu / sdac
즉, sdm, sdac, sdu에서 발생한 읽기 시간 초과는 해당 VM 저장소와 무관한 장치의 경고가 아닙니다. TXT에는 9월 18일 04:41:13부터 04:45:29까지 DID_TIME_OUT, READ I/O error, multipath 경로 실패와 복구가 반복됩니다. 반면 multipath 조회에서는 네 경로가 active ready running입니다. 조회 당시 복구돼 보인다는 사실과 장애 구간에 실제 경로 문제가 있었다는 사실을 구분해야 합니다.
새 Windows 화면에는 9월 18일 05:15:54의 OS 시작, 05:16:06에 기록된 이벤트 6008이 있습니다. 6008 메시지는 앞선 예기치 않은 종료 시각을 04:37:47로 보고합니다. 같은 부팅 뒤 E:의 NTFS 98과 덤프 생성 실패(volmgr 161)도 확인됩니다. 따라서 이제는 Windows 내부의 비정상 종료·재기동 기록까지 확보된 상태입니다. 호스트가 VM을 PowerOn으로 보고해도 게스트 OS가 멈추거나 재부팅할 수 있습니다.
다만 Windows가 보고한 04:37:47은 제출된 호스트 FC 오류의 첫 시각인 04:41:13보다 이릅니다. 이전 백업 로그의 실제 작업 시작도 04:38:12였습니다. 이 기록들만으로 “그 백업 명령이 먼저 FC 오류를 만들고 Windows를 종료했다”는 순서를 확정할 수 없습니다. 관리 서버의 예약 시각과 실제 호스트 실행 시각도 다릅니다. 동일 시각대의 다른 작업 부하, 각 시스템 시각 차이와 종료 전후 기록을 함께 대조해야 합니다.
권장 조치는 다음 순서입니다.
- FC 경로의 반복 장애를 먼저 정상화합니다. 스토리지·SAN 담당자가
mpatha에 해당하는 LUN을 기준으로 9월 18일 04:30부터 05:20까지 양쪽 HBA, FC 스위치, NetApp 포트/LUN의 지연·오류·경로 전환 기록을 대조해야 합니다. 여러 경로와 두 HBA에 걸친 오류이므로 현재 자료만으로 케이블 하나 또는 Windows 드라이버 하나를 원인으로 지정하지 않겠습니다. 확인 중에는 같은 저장소에 대량 백업·복제 작업이 몰리지 않도록 작업 일정을 조정하고, 운영 중 경로 초기화나 호스트 전체 재시작부터 시행하지 마세요.
- E:에 대해 복원 가능한 백업을 확보한 뒤 파일시스템을 복구합니다. 경로가 불안정한 채로 파일시스템을 수정하면 추가 손상 위험이 있습니다. 스토리지가 안정된 뒤 Windows VM에 RDP 또는 Mold 콘솔로 접속하여 관리자 PowerShell에서 현재 상태부터 확인해 주세요.
Get-Volume -DriveLetter E | Format-List DriveLetter,FileSystem,HealthStatus,OperationalStatus,Size,SizeRemaining
fsutil dirty query E:
NTFS 98은 E:의 전체 점검이 필요하다는 기록입니다. 백업의 복원 가능 여부를 확인하고 E:를 사용하는 업무 서비스를 정상 종료한 점검 시간에 아래 복구를 진행해야 합니다. 이 명령은 조회가 아니라 파일시스템을 변경하며, 볼륨 잠금·오프라인 전환 또는 재부팅이 필요할 수 있습니다. D:와 E:가 같은 가상 Disk 1에 있으므로 디스크 전체 작업을 한다면 D: 업무 영향도 함께 확인해야 합니다.
chkdsk E: /f
- 복구 후 실제 업무와 백업을 검증합니다. CHKDSK 완료 결과의 잔여 오류, E: 파일·애플리케이션 데이터 정상성, 네 FC 경로 상태를 먼저 확인합니다. 그 뒤 관찰 가능한 점검 시간에 백업을 검증하고, FC 읽기 시간 초과·vioscsi 129·NTFS 98·예기치 않은 재기동이 이후 작업 주기에서도 재발하지 않는지 확인해야 합니다. 백업이 한 번 완료됐다는 사실만으로 장애 해결로 판단하지는 않습니다.
VirtIO 드라이버 버전도 이미 제출해 주셨습니다. SCSI·네트워크·Balloon·Serial·GPU 드라이버는 화면상 100.103.104.30200으로 표시됩니다. 따라서 버전을 다시 요청하거나 확인 없이 재설치를 먼저 권하지 않겠습니다. 해당 드라이버와 현장 QEMU 조합의 알려진 문제 여부는 지원 조합을 대조해 검토할 사항이며, 현재 로그만으로 드라이버 결함이나 특정 패치가 해결책이라고 확정할 수는 없습니다.
마지막 화면의 9월 17일 DCOM 10010은 등록 시간 초과이고, 근처에 vioscsi 129도 있습니다. 시스템 지연과 함께 발생할 수 있지만 그것만으로 DCOM 권한 변경을 해결책으로 제시할 근거는 없습니다. 덤프 생성 실패 역시 정확한 BugCheck 코드를 대신해 주지는 않습니다.
이제 추가로 필요한 것은 이미 보내주신 TXT나 드라이버 화면 전체가 아니라, 스토리지 담당자가 확인한 해당 시각의 포트/LUN 원인과 조치 결과, 그리고 Windows의 04:37:47 종료부터 05:15:54 부팅 사이에 수동 리셋·재시작을 했는지입니다. 수동 조작이 없었다면 같은 구간의 원본 System 이벤트에서 41·1074·BugCheck 유무를 확인하면 다음 분기를 좁힐 수 있습니다. 공개 게시물에는 내부 주소·WWID·계정 등을 가려 주세요.
현재 제시한 것은 확인된 FC 경로 장애와 E: 오류를 안전하게 복구·검증하는 절차입니다. 최초 원인이 어느 장치나 소프트웨어인지까지 확정된 것은 아니므로, 실제 조치 결과를 받은 뒤 같은 맥락에서 최종 해결 여부를 판단하겠습니다.
