VMware ESXi 호스트에서 운영 중인 가상 머신(VM)의 스냅샷을 삭제하거나 디스크를 통합(Consolidate)할 때 "Unable to access a file since it is locked"(파일이 잠겨 있어 액세스할 수 없음) 오류가 자주 발생합니다. 이 문제는 대부분 VM 백업 소프트웨어의 오류와 관련이 있습니다. 필자 역시 Veeam, HPE/Micro Focus Data Protector, Veritas 환경에서 동일한 문제를 경험한 바 있습니다.
가상 디스크의 스냅샷 파일이 잠겨 있으면 다음 작업들이 정상적으로 수행되지 않습니다.
- 디스크 통합 — Virtual machine disks consolidation is needed 오류가 표시되는 경우
- Storage vMotion을 이용한 다른 데이터스토어로의 디스크 이동
- VM 백업 또는 현재 스냅샷 삭제
심한 경우 잠긴 가상 머신 자체를 전원 켜기조차 할 수 없습니다.
오류 메시지 예시
잠긴 가상 디스크 파일 또는 스냅샷에 대한 액세스 오류는 일반적으로 아래와 같은 형태로 나타납니다.
Unable to access file since it is locked.
An error occurred while consolidating disks: One or more disks are busy.
또한 다음과 같은 메시지가 출력되기도 합니다.
An error occurred while consolidating disks: msg.snapshot.error-DISKLOCKED.
주요 발생 원인
"파일이 잠겨 있어 액세스할 수 없음" 오류가 발생하는 대표적인 상황은 다음 두 가지입니다.
- 전원이 켜진 가상 머신의 일부 파일에, 다른 ESXi 호스트가 해당 파일을 잠그고 있다는 태그가 남아 있는 경우
- 백업 어플라이언스에 가상 디스크가 연결된 상태에서 백업 세션이 비정상 종료된 경우
잠금을 해제하려면 먼저 어떤 파일이 잠겨 있는지, 그리고 누가 잠그고 있는지를 파악해야 합니다.
1단계: 잠긴 파일 식별하기
- SSH 클라이언트로 문제의 VM이 등록된 ESXi 호스트에 접속합니다.
- 가상 머신 파일이 위치한 디렉터리로 이동합니다:
cd /vmfs/volumes/VMFS_DATASTORE_NAME/LOCKED_VM - vmware.log에서 잠금(lock) 관련 오류를 검색합니다:
cat vmware.log | grep lock
로그에는 다음과 같은 항목들이 기록되어 있습니다.
VigorSnapshotManagerConsolidateCallback: snapshotErr = Failed to lock the file (5:4008)
2020-09-09T05:07:11.432Z| vmx| I125: DISK: Cannot open disk "/vmfs/volumes/5121c3ff-2303a3a-33bb-12345678221/mun-web01/mun-web01_1-000002.vmdk": Failed to lock the file (16392).
2020-09-09T05:07:11.432Z| Worker#1| I125: DISKLIB-LIB : Failed to open '/vmfs/volumes/5121c3ff-2303a3a-33bb-12345678221/mun-web01/mun-web01-000002.vmdk' with flags 0xa Failed to lock the file (16392).
2020-09-09T05:07:11.432Z| vmx| I125: [msg.fileio.lock] Failed to lock the file
위 예제에서는 mun-web01_1-000002.vmdk 파일이 잠겨 있음을 알 수 있습니다.
2단계: 스냅샷 체인 및 잠금 소유자 확인
다음 명령으로 지정한 스냅샷부터 플랫(flat) 디스크까지의 현재 스냅샷 체인을 확인할 수 있습니다.
vmkfstools -qv10 mun-web01_1-000002.vmdk
이어서 스냅샷 정보와 잠금 소유자(RO Owner) 정보를 조회합니다.
vmkfstools -D mun-web01-000001-delta.vmdk
Lock [type 10c000021 offset 242835456 v 856, hb offset 3153920
gen 3, mode 1, owner 5cbac61a-4b6e32b7-0480-d06726ae7900 mtime 5199410
num 0 gblnum 0 gblgen 0 gblbrk 0]
RO Owner[0] HB Offset 3153920 5cbac61a-4b6e32b7-0480-d06726ae7900
Addr <4, 532, 83>, gen 859, links 1, type reg, flags 0, uid 0, gid 0, mode 600
RO Owner 항목에는 스냅샷 파일을 잠근 ESXi 호스트 네트워크 어댑터의 MAC 주소가 표시됩니다. 함께 표시되는 Mode 값도 중요한 단서가 됩니다.
- mode 1 — 읽기/쓰기 잠금 (전원이 켜진 VM 등)
- mode 2 — 대체로 백업 애플리케이션이 가상 디스크를 잠근 경우
3단계: MAC 주소로 ESXi 호스트 찾기
확인된 MAC 주소로 어떤 ESXi 서버가 파일을 잠그고 있는지 찾으려면 PowerCLI 명령을 활용할 수 있습니다. (앞서 확인한 MAC 주소를 콜론(:) 구분 형식으로 변환해서 사용하세요.)
Import-Module VMware.VimAutomation.Core -ErrorAction SilentlyContinue
connect-viserver mun-vcenter
Get-VMHost | Get-VMHostNetworkAdapter | Where-Object {$_.Mac -like "d0:67:26:ae:79:00"} | Format-List -Property *
참고로 IP 주소나 MAC 주소로 VMware vCenter에서 특정 VM을 찾는 방법도 유사하게 적용할 수 있습니다. 조회 결과의 VMHost 필드에서 해당 ESXi 호스트 이름을 확인할 수 있습니다.
또한 ESXi 호스트에서 직접 ARP 테이블을 조회해 VMkernel 네트워크에 속한 다른 ESXi 서버들의 IP 및 MAC 주소를 한꺼번에 확인하는 방법도 있습니다.
esxcli network ip neighbor list
4단계: 잠금 해제하기
잠금을 해제하는 가장 확실한 방법은 해당 ESXi 호스트를 재시작하는 것입니다. 재시작 전에 vMotion을 사용해 해당 호스트의 모든 VM을 미리 다른 호스트로 마이그레이션하세요.
호스트를 재시작할 수 없는 상황이라면, 호스트를 유지보수 모드(Maintenance Mode)로 전환한 뒤 SSH 콘솔에서 관리 에이전트(hostd)만 재시작하는 방법도 있습니다.
services.sh restart
완료 후 디스크 통합 또는 스냅샷 삭제 작업을 다시 시도합니다.
Veeam Backup & Replication 환경에서의 해결 방법
이 오류는 Veeam Backup & Replication에서 프록시 서버를 사용할 때 특히 자주 발생합니다. 백업 과정에서 오류가 생기면 Veeam이 가상 머신 디스크를 정상적으로 언마운트하지 못해 파일이 계속 잠긴 상태로 남게 됩니다.
이 경우 다음 절차로 문제를 해결할 수 있습니다.
- Veeam 프록시가 설치된 VM의 설정을 엽니다.
- 잠긴 파일이 있는 가상 디스크를 VM 하드웨어 목록에서 제거합니다.
이때 반드시 "Remove from virtual machine"(가상 머신에서 제거) 옵션을 선택해야 합니다. 만약 "Remove from virtual machine and delete files from disk(가상 머신에서 제거하고 디스크에서 파일 삭제)"를 선택하면 실제 vmdk 디스크 파일까지 삭제되어 데이터를 잃을 수 있으니 각별히 주의하세요.