Sửa lỗi VMware Disk needs repair sau mất điện: Phục hồi VMDK Snapshot

01. Tóm tắt nhanh cho kỹ sư IT#

Một máy ảo Windows Server vận hành trên VMware Workstation không thể khởi động sau sự cố mất điện. Giao diện báo “The parent of this virtual disk could not be opened”, làm người vận hành dễ nghi ngờ thiếu VMDK cha hoặc sai liên kết snapshot. Tuy nhiên, khi lần theo vmware.log, nguyên nhân gần nhất được phát hiện là một extent SPARSE trong snapshot trung gian báo “Disk needs repair (14)”.

Sau khi xác minh chuỗi CID/parentCID không có sai lệch, kỹ sư áp dụng vmware-vdiskmanager -R lên đúng descriptor của snapshot lỗi. VMware xác nhận sửa thành công. Kiểm tra -e với cả ba VMDK đang gắn vào VM đều trả về “Disk chain is consistent” và Exit Code 0. Đây là kết quả ở lớp ảo hóa, chưa thay thế việc hậu kiểm Windows, SQL Server và dữ liệu ứng dụng.

Điều cần nhớ trong 30 giây#

• Thông báo “parent could not be opened” là biểu hiện; lỗi thực tế có thể nằm sâu ở một extent thuộc snapshot tổ tiên.
• Không chỉnh CID/parentCID chỉ vì thấy lỗi parent — phải đối chiếu descriptor và log trước.
• Với VMDK split sparse, Repair bằng descriptor .vmdk của snapshot lỗi, không chỉ định file -s001.vmdk làm đầu vào.
• Chạy -R là thao tác sửa có ghi. Sao lưu đủ bộ file VM/chuỗi snapshot sang thiết bị khác trước khi sửa.
• Kết quả -e nhất quán không chứng minh dữ liệu hệ điều hành và cơ sở dữ liệu ứng dụng hoàn toàn nguyên vẹn.

02. Triệu chứng và bối cảnh sự cố#

Diễn biến ghi nhận#

Xem lớn ↗

Ba loại lỗi cần phân biệt#

03. Cấu trúc snapshot chain: lý do không được đoán theo số thứ tự#

Trong nhánh snapshot của ca này, chuỗi phụ thuộc đã được xác minh qua parentFileNameHint, CID và parentCID theo thứ tự BASE → 000004 → 000006 → 000007 → 000005 → 000008. Số hậu tố không nhất thiết tăng đều theo nhánh đang vận hành.

Xem lớn ↗

CID và parentCID hoạt động như thế nào?#

Mỗi descriptor VMDK ghi CID của nó và parentCID dự kiến của disk cha. Để liên kết hợp lệ, parentCID của VMDK con phải bằng CID của descriptor VMDK cha mà parentFileNameHint chỉ tới. Base disk có parentCID=ffffffff. Đây là kiểm tra tính nhất quán liên kết, không phải kiểm tra checksum toàn bộ extent.

Các CID trong bảng là giá trị giả lập nhất quán để dùng công khai, không phải CID gốc của hệ thống.

Split sparse VMDK gồm những gì?#

Với createType="twoGbMaxExtentSparse", snapshot có một descriptor văn bản nhỏ và nhiều file extent như ServerOS-000006-s001.vmdk, ServerOS-000006-s002.vmdk… Mỗi RW/SPARSE trong descriptor mô tả một vùng dung lượng logic của đĩa. File s001 đang tồn tại và có dung lượng vật lý khác 0 vẫn có thể chứa metadata sparse cần sửa.

# Minh họa descriptor VMDK đã thay tên/CID
CID=30ce42dd
parentCID=20bd31ef
createType="twoGbMaxExtentSparse"
parentFileNameHint="ServerOS-000004.vmdk"
RW 33554432 SPARSE "ServerOS-000006-s001.vmdk"
RW 33554432 SPARSE "ServerOS-000006-s002.vmdk"

Xem lớn ↗

04. Điều tra chính xác bằng vmware.log và PowerShell#

Bước 1 — Giữ hiện trạng#

• Tắt VM và ngừng thử Power On lặp lại. Ghi nhận phiên bản Workstation, danh sách VMDK đang gắn và dung lượng trống host.
• Nếu nghi ngờ ổ nguồn có dấu hiệu lỗi đọc, ưu tiên tạo image/bản sao có kiểm soát trước mọi công cụ repair.
• Không Revert/Delete Snapshot, không Consolidate, không chỉnh CID và không chạy CHKDSK /f trên nguồn ngay lập tức.

Bước 2 — Đọc lỗi có ý nghĩa trong vmware.log#

$vmDir = 'D:\VM-Lab\WindowsServer-VM'
$log = Join-Path $vmDir 'vmware.log'
Get-Content -LiteralPath $log -Tail 500 |
  Select-String -Pattern 'DISKLIB-SPARSE|DISKLIB-CHAIN|Disk needs repair|Failed to open|000006' |
  Select-Object -Last 60

Đoạn log tiêu biểu đã ẩn danh:

DISKLIB-SPARSE: "...ServerOS-000006-s001.vmdk"
  failed to open (14): Disk needs repair.
DISKLIB-LINK: Failed to open "...ServerOS-000006.vmdk"
  The specified virtual disk needs repair.
DISKLIB-CHAIN: "...ServerOS-000008.vmdk"
  Failed to open parent "...ServerOS-000006.vmdk".

Suy luận: vùng lỗi trực tiếp được chỉ tên là extent 000006-s001; lỗi parent trên snapshot đỉnh là hệ quả truyền qua chuỗi. Không được khẳng định chắc nội dung file bị mất hoặc bad sector chỉ từ thông báo này.

Bước 3 — Liệt kê descriptor và đối chiếu liên kết#

$vmDir = 'D:\VM-Lab\WindowsServer-VM'
$stem = 'ServerOS'
$ids = @('', '-000004', '-000006', '-000007', '-000005', '-000008')
foreach ($id in $ids) {
    $file = Join-Path $vmDir ($stem + $id + '.vmdk')
    Write-Host "===== $([IO.Path]::GetFileName($file)) ====="
    if (Test-Path -LiteralPath $file -PathType Leaf) {
        Get-Content -LiteralPath $file -TotalCount 12 |
          Select-String '^(CID|parentCID|parentFileNameHint)='
    } else { Write-Host 'MISSING DESCRIPTOR' }
}

Chỉ đọc những file descriptor đã biết tên. Không dùng Get-Content để trích text từ file nhị phân extent -sNNN.vmdk.

Bước 4 — Kiểm tra extent được khai báo#

$desc = Join-Path $vmDir 'ServerOS-000006.vmdk'
$extents = @(Get-Content -LiteralPath $desc | ForEach-Object {
    if ($_ -match '^RW\s+\d+\s+SPARSE\s+"([^"]+)"') {
        $Matches[1]
    }
})
$missing = @($extents | Where-Object {
    -not (Test-Path -LiteralPath (Join-Path $vmDir $_) -PathType Leaf)
})
"Declared extents: $($extents.Count)"
"Missing extents: $($missing.Count)"
$missing

Nếu extent thiếu, cần truy tìm/khôi phục trước. Nếu không thiếu, vẫn chưa chứng minh nội dung và metadata của từng extent hợp lệ.

05. Quy trình khôi phục an toàn, có thể kiểm toán#

Xem lớn ↗

Điều kiện trước khi chạy -R#

• VM phải tắt hoàn toàn, không ở trạng thái suspended; đóng Workstation, kiểm tra không có tiến trình nào dùng bộ VMDK liên quan.
• Có bản sao đầy đủ, độc lập của VM ở thiết bị khác nếu có thể; không chỉ chép descriptor 000006 mà bỏ các extent/parent.
• Đảm bảo nguồn điện ổn định và ổ lưu trữ không có dấu hiệu lỗi vật lý đang diễn tiến.
• Nếu phải cứu gấp trên bản gốc, coi đó là phương án rủi ro cao; cần ghi nhận quyết định và không gọi là quy trình chuẩn.

Bước 5 — Định vị vmware-vdiskmanager#

$tool = 'C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager.exe'
if (-not (Test-Path -LiteralPath $tool)) {
    throw 'Không tìm thấy vmware-vdiskmanager.exe; kiểm tra thư mục cài đặt.'
}

Bước 6 — Repair đúng descriptor snapshot lỗi#

Đoạn dưới minh họa thao tác trên thư mục bản sao độc lập. Đường dẫn E: chỉ là ví dụ; đừng chạy nếu E: không chứa bộ VM đã được sao lưu đầy đủ.

$recoveryDir = 'E:\VM-Recovery-Copy\WindowsServer-VM'
$target = Join-Path $recoveryDir 'ServerOS-000006.vmdk'
if (-not (Test-Path -LiteralPath $target)) { throw 'Missing descriptor.' }
& $tool -R $target
"Repair exit code: $LASTEXITCODE"

Kết quả đã được ghi nhận trong ca thực tế, trình bày lại với đường dẫn ẩn danh:

The virtual disk, '...\ServerOS-000006.vmdk',
was corrupted and has been successfully repaired.

Không chạy -R vào “ServerOS-000008.vmdk” chỉ vì tên ấy xuất hiện trên popup. Không chạy thẳng vào extent “-s001.vmdk”. Trong case này điểm hỏng đã được log xác nhận ở descriptor/snapshot 000006.

Bước 7 — Xác minh chuỗi snapshot đỉnh và các ổ còn lại#

$disks = @(
  'ServerOS-000008.vmdk',
  'ServerData-000005.vmdk',
  'AdditionalDisk-000005.vmdk'
)
foreach ($disk in $disks) {
    Write-Host "Checking: $disk"
    & $tool -e (Join-Path $recoveryDir $disk)
    Write-Host "Exit Code: $LASTEXITCODE"
}

Trong dữ liệu ca thật, cả ba chuỗi đều trả “Disk chain is consistent.” với Exit Code 0. Kết quả này không thay thế kiểm tra boot, NTFS, ứng dụng và SQL Server.

06. Bằng chứng kết quả thực tế và giới hạn kết luận#

Xem lớn ↗

Tại thời điểm kết thúc log được cung cấp, chưa có biên bản hậu kiểm Windows/SQL hoặc bằng chứng database được xác nhận ONLINE. Do đó bài viết chỉ tuyên bố phục hồi thành công tính nhất quán chuỗi VMDK, không tuyên bố phục hồi hoàn tất hệ thống ứng dụng.

Checklist sau khi VM có thể khởi động#

1. Power On từ bản sao đã kiểm chứng; ghi lại mọi cảnh báo I/O, filesystem hoặc tự động sửa đĩa.
2. Xác nhận Windows boot, nhận đủ volume và dịch vụ thiết yếu; không cho người dùng ghi mới ngay nếu cần bảo tồn pháp y.
3. Kiểm tra SQL Server service, SQL Error Log, trạng thái từng database (ONLINE/SUSPECT/RECOVERY_PENDING).
4. Ưu tiên bản SQL backup hợp lệ ra nơi lưu trữ độc lập; đánh giá mức độ nhất quán giao dịch.
5. Sau khi có bản bảo vệ và đánh giá I/O, chạy DBCC CHECKDB phù hợp để kiểm tra logic/physical integrity. Tuyệt đối không tự động dùng REPAIR_ALLOW_DATA_LOSS.
6. Chỉ mở lại ứng dụng nghiệp vụ sau kiểm thử mẫu nghiệp vụ và phê duyệt vận hành.

-- Ví dụ kiểm tra trạng thái; thực hiện trên SQL instance được phép
SELECT name, state_desc, recovery_model_desc
FROM sys.databases ORDER BY name;
 
-- Đọc tính toàn vẹn DB khi đã có kế hoạch bảo vệ phù hợp
DBCC CHECKDB (N'<DatabaseName>') WITH NO_INFOMSGS;

07. Thiết kế phòng ngừa cho máy ảo lưu dữ liệu quan trọng#

Xem lớn ↗

Split 2 GB hay single-file VMDK?#

Đề xuất vận hành: phân tách các VMDK theo chức năng (OS, SQL data, SQL log) nếu nhu cầu quản trị phù hợp; chọn một file VMDK lớn cho mỗi đĩa khi nền tảng lưu trữ cho phép. Không chuyển đổi định dạng trên máy ảo chưa được backup; dùng clone để migration, sau đó xác minh dữ liệu.

Snapshot không phải Backup#

AutoProtect có thể tạo nhiều nhánh snapshot theo thời gian. Đây là công cụ rollback trong thời gian ngắn, không thay thế bản backup độc lập, đặc biệt đối với SQL Server. Tránh giữ chuỗi snapshot kéo dài trên máy chủ thực tế; lên kế hoạch backup ứng dụng, backup VM, kiểm tra restore và nguồn UPS.

Khuyến nghị kỹ thuật triển khai#

• UPS có giám sát và shutdown an toàn cho host; kiểm tra lại tình trạng pin định kỳ.
• Theo dõi dung lượng host còn trống, độ tăng trưởng delta VMDK, SMART/RAID và Event Viewer theo đúng provider storage.
• Backup SQL native (full/differential/log tùy recovery model) và bản sao VM độc lập.
• Kiểm thử restore định kỳ và lưu nhật ký thao tác recovery để tái lập.
• Không dựa vào việc Run as Administrator như cách sửa mặc định: thao tác này có thể vượt qua lỗi quyền, nhưng không sửa được sparse metadata hỏng.

08. Bảng quyết định nhanh khi kết quả không như mong đợi#

09. FAQ — Câu hỏi kỹ thuật thường gặp#

10. Nguồn tham khảo và phạm vi đối chiếu#

Tài liệu ca thực tế đã ẩn danh do TUNGTEK cung cấp là nguồn cho kết quả -R và 3/3 chain consistent, Exit Code 0. Tài liệu hãng bên dưới giải thích cơ chế và quy trình; không phải kiểm thử độc lập ca này.

Nguồn AutoProtect bên dưới dành cho VMware Fusion; dùng tham chiếu nguyên lý snapshot phụ thuộc, không coi là ma trận hỗ trợ Workstation 17.x.

• Broadcom KB 329347 — Repairing a virtual disk in Workstation ↗
• Broadcom — Understanding snapshots and AutoProtect in VMware Fusion ↗
• Broadcom — Backing up a VMware Workstation virtual machine ↗
• Microsoft Learn — DBCC CHECKDB ↗
• Broadcom — Converting between single and split virtual disks ↗

11. Bước tiếp theo khi cần hỗ trợ#

Giữ bản gốc, ghi lại thao tác đã làm và chuẩn bị danh sách dữ liệu ưu tiên. TUNGTEK tiếp nhận hiện trạng để thống nhất bước khảo sát phù hợp. Không gửi log chứa dữ liệu nhận diện hoặc file VM nhạy cảm lên bình luận công khai.