Khi chuỗi Snapshot “đứt gánh giữa đường”
Sáng thứ Hai, ly cafe trên tay chưa kịp nguội thì hệ thống monitoring đã réo liên hồi. Một máy ảo SQL Server quan trọng, nặng gần 500GB, bỗng dưng không thể khởi động sau khi tiến trình backup hàng đêm gặp sự cố. Bấm Power On trên vCenter, mình nhận ngay một dòng thông báo đỏ rực: “The parent virtual disk has been modified since the child was created…”.
Với dân quản trị hệ thống, đây chính là lỗi CID mismatch kinh điển. Tại cụm Cluster 8 host ESXi mình đang quản lý, lỗi này thường xuyên xuất hiện sau khi điện chập chờn hoặc phần mềm Veeam bị treo giữa chừng. Bình tĩnh nhé, dữ liệu của bạn thường vẫn còn nguyên đó. Chỉ là “sợi dây” liên kết giữa các file snapshot đang bị lệch một mắt xích mà thôi.
CID và Parent CID: Những con số biết nói
Để sửa lỗi, bạn cần hiểu bản chất của nó. Mỗi ổ đĩa ảo (.vmdk) gồm hai phần: file dữ liệu thực tế (-flat.vmdk hoặc -delta.vmdk) và một file text mô tả (descriptor). File descriptor này rất nhẹ, chỉ vài KB nhưng lại giữ vai trò điều hướng cực kỳ quan trọng.
Bên trong file descriptor, bạn sẽ thấy thông số CID (Content ID) – một mã hex 8 ký tự dùng để nhận diện trạng thái nội dung disk.
- CID: Mã định danh của chính file hiện tại.
- parentCID: Mã định danh của file “cha” mà nó đang dựa vào.
Khi bạn tạo Snapshot, VMware sinh ra một file delta mới. File này sẽ lưu parentCID trùng khớp với CID của file gốc. Nếu file gốc bị thay đổi mã CID vì bất kỳ lý do gì, VMware sẽ chặn khởi động máy ảo ngay lập tức. Đây là cơ chế bảo vệ để tránh ghi đè dữ liệu sai lệch, nhưng cũng là cơn ác mộng nếu bạn đang cần khôi phục dịch vụ gấp.
Tại sao lỗi CID mismatch lại xảy ra?
Qua những lần “chinh chiến” thực tế, mình đúc kết được 3 nguyên nhân phổ biến nhất:
- Sự cố phần mềm backup: Các công cụ như Veeam hay Nakivo tạo snapshot tạm thời để copy dữ liệu. Nếu tiến trình bị ngắt đột ngột, nó có thể cập nhật CID file gốc nhưng lại quên cập nhật file snapshot con.
- Can thiệp file VMDK thủ công: Ai đó tò mò mở file descriptor ra sửa hoặc mount ổ đĩa vào máy ảo khác để lấy dữ liệu rồi trả về.
- Metadata bị lỗi: Một cú sập nguồn bất ngờ khiến metadata trên Datastore bị ghi đè sai lệch.
Các bước xử lý lỗi CID mismatch thực tế
Chúng ta sẽ can thiệp trực tiếp vào file descriptor qua dòng lệnh. Hãy chuẩn bị sẵn tài khoản root và bật SSH lên.
Bước 1: Truy tìm mắt xích bị đứt qua log
Đừng đoán mò giữa rừng file snapshot. Hãy truy cập vào thư mục máy ảo trên Datastore và tìm file vmware.log. Sử dụng lệnh grep để tìm chính xác vị trí lỗi:
grep -i "CID mismatch" vmware.logBạn sẽ thấy kết quả tương tự thế này:
Parent CID (fb123456) does not match expected CID (ab654321)Dòng log này tiết lộ: File con đang mong đợi cha của nó có mã ab654321, nhưng thực tế ông cha lại đang mang mã fb123456.
Bước 2: Truy cập SSH vào host ESXi
Bật dịch vụ SSH trên host qua vSphere Client (Host > Manage > Services > TSM-SSH > Start). Sau đó, dùng PuTTY hoặc Terminal để login.
Di chuyển đến thư mục chứa máy ảo (thường ở /vmfs/volumes/[tên-datastore]/[tên-vm]/). Liệt kê các file descriptor đang có:
ls -l *.vmdkHãy nhớ: Chỉ thao tác với các file không có hậu tố -flat hoặc -delta.
Bước 3: Đồng bộ lại chuỗi CID
Bạn có hai lựa chọn: Sửa CID file cha hoặc sửa parentCID file con. Phương án an toàn nhất là sửa parentCID của file con cho khớp với thực tế của cha.
Dùng trình soạn thảo vi để mở file con:
vi Sheehan-000003.vmdkTìm dòng parentCID. Nhấn phím i để chuyển sang chế độ chỉnh sửa. Hãy đổi giá trị cũ thành mã thực tế mà bạn vừa tìm thấy ở Bước 1 (ví dụ: fb123456). Sau đó nhấn Esc, gõ :wq và Enter để lưu lại.
Cách xử lý triệt để và an toàn hơn
Nếu chuỗi snapshot quá dài, việc sửa tay từng file rất dễ gây nhầm lẫn. Trong trường hợp đó, mình thường áp dụng hai mẹo sau:
- Consolidate Snapshots: Sau khi sửa CID để máy nhận diện được ổ đĩa, hãy chuột phải vào VM > Snapshots > Consolidate. Thao tác này sẽ gộp sạch các file delta vào file gốc.
- Clone máy ảo: Nếu lo ngại rủi ro, hãy Clone máy ảo ra một bản sao mới. Quá trình Clone sẽ tự động làm phẳng (flatten) toàn bộ snapshot và tạo ra bộ CID mới đồng bộ hoàn toàn.
Lưu ý “xương máu” cho quản trị viên
Vận hành hệ thống ảo hóa, bạn nên nằm lòng những quy tắc này:
- Luôn backup file descriptor trước khi sửa: Chỉ mất 2 giây để gõ
cp file.vmdk file.vmdk.baknhưng nó sẽ cứu bạn nếu lỡ tay xóa nhầm nội dung. - Quy tắc file gốc: File gốc (Base Disk) không có cha, nên
parentCIDcủa nó luôn cố định làffffffff. Đừng bao giờ thay đổi con số này. - Tắt máy ảo khi thao tác: Đảm bảo máy ảo đã tắt hoàn toàn trước khi can thiệp vào file descriptor để tránh tranh chấp quyền ghi.
Xử lý CID mismatch không khó nếu bạn nắm vững nguyên lý “cha nào con nấy”. Thay vì tốn 5-6 tiếng restore hàng Terabyte dữ liệu, việc sửa vài dòng text này chỉ tiêu tốn của mình chưa đầy 5 phút. Hy vọng kinh nghiệm này giúp bạn tự tin hơn khi đối mặt với những dòng log báo lỗi trên VMware.
