Posted inVMware

Nâng cấp VM Hardware Version: Đừng để máy ảo ‘chạy hụt hơi’ trên vSphere đời mới

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

2 giờ sáng, điện thoại mình rung bần bật. Đầu dây bên kia là ông bạn đồng nghiệp đang trực vận hành hệ thống ERP với giọng khá hốt hoảng. Con SQL Server bỗng nhiên chậm chạp một cách vô lý sau khi vừa migrate sang cụm Cluster ESXi 8.0 mới. Kiểm tra nhanh, mình phát hiện VM này vẫn đang chạy Hardware Version 8 từ thời ESXi 5.0.

Tình huống này cực kỳ phổ biến trong giới SysAdmin. Chúng ta thường mải mê nâng cấp Host ESXi mà quên mất việc “thay áo” cho đám máy ảo bên trong. Chạy VM đời cũ trên Hypervisor mới giống như gắn động cơ Tesla vào khung xe Cub 81. Nó vẫn chạy được, nhưng chắc chắn bạn sẽ không bao giờ chạm tới giới hạn tốc độ tối đa.

Tại sao bạn cần nâng cấp VM Hardware Version ngay?

Mỗi phiên bản VMware ESXi sẽ đi kèm với một bộ “phần cứng ảo” tương ứng. Khi bạn nâng cấp phiên bản này (nay gọi là VM Compatibility), máy ảo sẽ được giải phóng sức mạnh đáng kể:

  • Mở rộng giới hạn tài nguyên: Hardware Version 20 (ESXi 8.0) hỗ trợ tới 448 vCPU và 6TB RAM. Con số này vượt xa mức 32 vCPU và 1TB RAM của bản Version 8 cũ kỹ.
  • Hỗ trợ công nghệ mới: Bạn sẽ có NVMe Controller cho tốc độ đĩa cực cao, vTPM để cài Windows 11, hoặc tính năng Secure Boot giúp tăng cường bảo mật.
  • Tối ưu hóa I/O: Giảm đáng kể độ trễ khi Guest OS giao tiếp với Hypervisor, giúp các ứng dụng database phản hồi nhanh hơn.

Trong một lần chuyển workload sang Proxmox làm Lab, mình thấy họ quản lý Machine Type (q35/i440fx) khá linh hoạt. Tuy nhiên, VMware lại khắt khe hơn về tính tương thích ngược. Chính vì thế, bạn cần một chiến thuật nâng cấp bài bản để tránh rủi ro sập hệ thống.

So sánh 3 phương án triển khai phổ biến

Phương pháp Ưu điểm Nhược điểm
Nâng cấp tức thì Áp dụng ngay, thấy kết quả lập tức. Bắt buộc tắt máy ảo. Rủi ro nếu quên snapshot.
Lên lịch (Scheduled) An toàn, tự động chạy khi reboot. Phải chờ đến kỳ bảo trì tiếp theo.
PowerCLI Xử lý hàng loạt hàng trăm VM. Dễ gây lỗi diện rộng nếu script chưa chuẩn.

Cảnh báo: Con đường không có lối thoát?

Nâng cấp Hardware Version có một đặc điểm cần lưu ý: Bạn không thể hạ cấp (Downgrade) qua giao diện GUI. Một khi đã lên bản 20, bạn không thể quay về bản cũ trừ khi khôi phục từ backup hoặc can thiệp thủ công vào file .vmx. Việc sửa file .vmx tiềm ẩn rủi ro cực lớn cho dữ liệu production.

Lời khuyên của mình là luôn ưu tiên Scheduled Upgrade kết hợp Snapshot. Đừng bao giờ làm tắt nếu không muốn sáng mai phải ngồi viết báo cáo giải trình vì server ngừng hoạt động.

Quy trình nâng cấp chuẩn “chuyên gia”

Bước 1: Ưu tiên VMware Tools

Đây là quy tắc bất di bất dịch: Luôn nâng cấp VMware Tools trước. Nếu làm ngược lại, VM có thể không nhận driver card mạng hoặc controller đĩa. Kết quả thường thấy là lỗi màn hình xanh (BSOD) hoặc mất kết nối mạng hoàn toàn.

Bước 2: Tạo “phao cứu sinh” với Snapshot

Đừng quá tự tin vào tay nghề. Hãy chuột phải vào VM, chọn Snapshots -> Take Snapshot. Đặt tên rõ ràng như “Pre-HW-Upgrade” để dễ dàng quay lại nếu có sự cố.

Bước 3: Lên lịch nâng cấp thông minh

Thay vì chọn nâng cấp ngay, mình thường dùng tính năng Schedule để giảm thiểu downtime:

  1. Chuột phải vào VM đang chạy, chọn Compatibility -> Schedule VM Compatibility Upgrade.
  2. Chọn phiên bản cao nhất mà Host hỗ trợ (ví dụ: ESXi 8.0 and later).
  3. Đánh dấu vào ô Only upgrade after a normal guest OS shutdown.

Cách này rất hay vì VM vẫn hoạt động bình thường. Khi hệ thống tự khởi động lại vào khung giờ bảo trì, VMware sẽ nâng cấp phần cứng chỉ trong vài giây trước khi boot vào OS.

Tự động hóa cho hệ thống lớn

Nếu danh sách lên tới 50-100 VM, việc click chuột từng con là một cực hình. Đoạn script PowerCLI dưới đây sẽ giúp bạn lên lịch nâng cấp cho toàn bộ Resource Pool trong tích tắc:

# Kết nối vCenter
Connect-VIServer -Server vcenter.yourdomain.com

# Quét toàn bộ VM trong Resource Pool cụ thể
$vms = Get-ResourcePool "Production_Pool" | Get-VM

foreach ($vm in $vms) {
    Write-Host "Đang lên lịch cho: $($vm.Name)" -ForegroundColor Cyan
    $vmView = $vm | Get-View
    $spec = New-Object VMware.Vim.VirtualMachineConfigSpec
    $spec.ScheduledHardwareUpgradeInfo = New-Object VMware.Vim.ScheduledHardwareUpgradeInfo
    $spec.ScheduledHardwareUpgradeInfo.UpgradePolicy = "always"
    $spec.ScheduledHardwareUpgradeInfo.VersionKey = "vmx-19" # ESXi 7.0 U2
    
    $vmView.ReconfigVM($spec)
}
Disconnect-VIServer -Confirm:$false

Những bài học “xương máu” từ thực tế

Sau nhiều năm quản lý các cụm Cluster lớn, mình rút ra 3 lưu ý quan trọng:

  1. Lỗi Ghost NIC trên Windows: Sau khi nâng cấp, Windows có thể nhận diện card mạng cũ là thiết bị ẩn (Ghost NIC) và tạo ra card mới (Network Adapter #2). Bạn sẽ phải cấu hình lại IP tĩnh từ đầu.
  2. Bản quyền phần mềm: Một số app kế toán hoặc ERP cũ khóa license theo Hardware ID. Thay đổi Hardware Version có thể làm mất bản quyền, hãy check kỹ với NCC phần mềm.
  3. Rào cản vMotion: Nếu cụm Cluster chạy hỗn hợp Host cũ (6.7) và mới (7.0), đừng nâng cấp VM lên version mà Host cũ không hiểu. Nếu không, bạn sẽ không thể di chuyển VM sang Host cũ khi cần cứu hộ.

Nâng cấp phần cứng ảo không chỉ là đuổi theo những con số. Đó là cách bạn bảo vệ và tối ưu khoản đầu tư vào hạ tầng server đắt đỏ. Hy vọng những chia sẻ này giúp các bạn có những đêm trực yên bình hơn!

Share:
Tags: