Xử lý lỗi màn hình tím (PSOD) trên VMware ESXi: Từ ‘bắt bệnh’ đến trị tận gốc

VMware tutorial - IT technology blog
VMware tutorial - IT technology blog

PSOD: ‘Nỗi ám ảnh’ tím ngắt của quản trị viên

Nếu Windows có màn hình xanh thì VMware ESXi có màn hình tím, gọi là PSOD (Purple Screen of Death). Tôi từng trực vận hành cho một ngân hàng lớn khi một con Host chứa hơn 40 VM quan trọng bỗng dưng ‘đột tử’. Truy cập iDRAC, đập vào mắt là một màu tím ngắt với chi chít mã hex. Cảm giác lúc đó thực sự rất căng thẳng.

Thực tế, PSOD xuất hiện khi VMkernel gặp lỗi nghiêm trọng không thể tự phục hồi. Thay vì chạy tiếp và làm hỏng dữ liệu, hệ thống chọn cách dừng lại để bảo vệ tính toàn vẹn. Làm chủ PSOD giúp bạn phân biệt nhanh lỗi do thanh RAM hỏng hay do Driver xung đột. Đây là kỹ năng sống còn để giảm Downtime cho doanh nghiệp.

Cấu hình Core Dump: Đừng để hệ thống ‘chết’ trong im lặng

Khi PSOD xảy ra, toàn bộ dữ liệu trên RAM sẽ được ghi xuống phân vùng Core Dump. Nếu quên cấu hình mục này, mọi dấu vết về nguyên nhân lỗi sẽ tan biến ngay khi bạn khởi động lại máy. Đừng để rơi vào cảnh hệ thống treo liên tục mà không có một dòng log nào để lại.

1. Kiểm tra phân vùng Dump hiện có

Thông thường ESXi sẽ tự tạo phân vùng này khi cài đặt. Hãy dùng lệnh SSH sau để kiểm tra xem Host của bạn đã có nơi lưu trữ “di chúc” chưa:

esxcfg-dumppart -l

Nếu kết quả trống rỗng, bạn đang chạy trên một hệ thống cực kỳ rủi ro. Hãy thiết lập ngay.

2. Cách tạo Dump File trên Datastore

Với các máy chủ cài ESXi trên USB hoặc thẻ nhớ SD, hệ thống thường không có phân vùng dump mặc định. Bạn nên tạo một file dump khoảng 2GB trên ổ cứng (SSD/HDD) để đảm bảo lưu đủ dữ liệu:

# Tạo file dump 2GB trên Datastore
esxcli system coredump file add -d DATASTORE_NAME -f psod-dump-file

# Kích hoạt file vừa tạo
esxcli system coredump file set -p /vmfs/volumes/DATASTORE_NAME/vmkdump/psod-dump-file

# Xác nhận lại trạng thái
esxcli system coredump file list

Bí kíp ‘đọc vị’ màn hình tím như chuyên gia

Đừng vội nhấn nút Reset. Hãy chụp lại màn hình hoặc dùng điện thoại quay lại toàn bộ nội dung. Có 3 thông số vàng bạn cần soi kỹ:

  • Exception Type: Ví dụ Page Fault thường liên quan đến bộ nhớ, còn Machine Check Exception (MCE) 99% là do phần cứng.
  • Backtrace: Đây là lịch sử các hàm CPU thực thi trước khi sập. Nếu thấy tên các module như lpfc (Emulex) hay i40en (Intel), bạn đã tìm đúng thủ phạm gây xung đột Driver.
  • Server Uptime: Nếu máy sập chỉ sau vài phút hoạt động, khả năng cao là lỗi vật lý hoặc tản nhiệt.

Trích xuất dữ liệu sau khi khởi động lại

Sau khi ép máy khởi động lại, hãy chuyển file dump sang định dạng văn bản để phân tích sâu hơn. Đừng mò mẫm trong bóng tối.

# Trích xuất log từ phân vùng dump
esxcfg-dumppart -L /vmfs/volumes/DATASTORE_NAME/vmkdump/analysis.log

# Tìm kiếm nhanh các lỗi liên quan
grep -i "coredump" /var/log/vmware/vobd.log

Mẹo nhỏ: Hãy copy dòng lỗi đầu tiên của PSOD và tìm trên VMware Knowledge Base (KB). Phần lớn các lỗi Driver phổ biến đều đã có bản vá (patch) chính thức từ hãng.

Ví dụ thực tế: Khi phần cứng ‘lên tiếng’

Nếu gặp dòng Machine Check Exception (MCE), hãy chuẩn bị tinh thần thay đồ mới. MCE là tín hiệu CPU báo cáo lỗi phần cứng không thể sửa chữa. Trong một ca xử lý thực tế, tôi kiểm tra log iDRAC sau khi thấy MCE và phát hiện thanh RAM số 4 bị lỗi ECC (Error Correction Code). Thay thanh RAM đó, hệ thống chạy ổn định suốt 2 năm sau.

Phòng bệnh hơn chữa bệnh: Quy trình 3 bước

Để không phải thức đêm vì PSOD, bạn cần duy trì kỷ luật vận hành khắt khe.

1. Đồng bộ Firmware và Driver (HCL)

Sai lầm kinh điển là chỉ cập nhật ESXi mà bỏ quên BIOS, Card mạng hay Card RAID. Sự lệch pha giữa Driver của OS và Firmware phần cứng là ‘mảnh đất màu mỡ’ cho PSOD. Hãy luôn đối chiếu với bảng VMware Compatibility Guide (HCL).

2. Giám sát tập trung qua Syslog

Đừng đợi máy tím mới đi tìm log. Hãy đẩy toàn bộ log về một máy chủ tập trung như vRealize Log Insight hoặc Syslog Server. Khi Host ‘chết’, bạn vẫn có dữ liệu tại máy chủ khác để mổ xẻ nguyên nhân.

# Cấu hình đẩy log về Server trung tâm
esxcli system syslog config set --loghost='udp://192.168.1.100:514'
esxcli system syslog reload

3. Thử nghiệm giả lập (Chỉ dùng cho Lab)

Muốn biết hệ thống của mình phản ứng ra sao khi gặp sự cố? Bạn có thể chủ động tạo một cú ‘crash’ giả định bằng lệnh sau. Lưu ý: Lệnh này sẽ làm sập Host ngay lập tức, tuyệt đối không dùng trên Production.

vsish -e set /reliability/crashMe/Panic 1

Sau khi chuyển dịch nhiều hệ thống từ VMware sang Proxmox, tôi nhận thấy dù Proxmox linh hoạt nhưng cơ chế Core Dump của ESXi vẫn cực kỳ chi tiết. Nếu biết cách khai thác, bạn sẽ luôn làm chủ được tình hình. Hãy luôn giữ Firmware mới nhất và đừng quên chụp ảnh màn hình khi máy ‘tím’.

Share: