Sau 6 tháng quản lý cluster VMware với 8 host ESXi, mình đúc kết được một bộ checklist mà phần lớn tài liệu online bỏ qua. VM đang chạy chậm, CPU usage cao bất thường, disk I/O lag? Bài này đi thẳng vào debug và fix từng bước — không lý thuyết dài dòng.
Quick Start: 3 việc làm ngay trong 5 phút
Trước khi đào sâu vào cấu hình, có 3 thứ cần kiểm tra ngay khi VM có vấn đề hiệu suất.
1. Cài VMware Tools (nếu chưa có)
Lỗi này mình gặp mỗi lần tiếp nhận hạ tầng từ team cũ. VM không có VMware Tools giống xe không có nhớt — chạy được, nhưng hao mòn và chậm hơn hẳn. Tools cung cấp paravirtual drivers cho memory, balloon driver, và time synchronization chính xác.
Trên Ubuntu/Debian:
sudo apt update && sudo apt install open-vm-tools open-vm-tools-desktop -y
sudo systemctl enable open-vm-tools && sudo systemctl start open-vm-toolsTrên CentOS/RHEL/Rocky Linux:
sudo yum install open-vm-tools -y
sudo systemctl enable vmtoolsd && sudo systemctl start vmtoolsd
# Xác nhận đã chạy
vmware-toolbox-cmd -v2. Kiểm tra balloon driver có đang inflate không
VMware dùng balloon driver để thu hồi RAM từ VM khi host thiếu bộ nhớ. Nếu balloon đang phình to, VM bị lấy RAM mà không hay biết gì — nguyên nhân số 1 gây chậm khó nhận ra từ bên trong guest OS.
Kiểm tra trên vSphere Client: VM → Monitor → Memory → Balloon. Giá trị Balloon > 0 MB nghĩa là host đang thiếu RAM và đang lấy bộ nhớ từ VM của bạn.
3. Đổi sang PVSCSI và VMXNET3
Trong VM Settings, đổi:
- Hard Disk adapter: từ LSI Logic SCSI → VMware Paravirtual (PVSCSI)
- Network Adapter: từ E1000 → VMXNET3
Kết quả cụ thể: CPU usage của một VM database giảm từ 15% xuống 8% chỉ sau bước đổi disk adapter. PVSCSI và VMXNET3 là paravirtual driver — VMware xử lý I/O trực tiếp, không giả lập phần cứng vật lý, overhead thấp hơn hẳn so với LSI hay E1000.
Giải thích chi tiết: CPU và RAM
Thêm vCPU đôi khi làm VM chậm hơn
Nghe có vẻ counter-intuitive, nhưng đây là điều mình phải giải thích cho team khá nhiều lần. VMware dùng cơ chế co-scheduling: để chạy một VM có nhiều vCPU, hypervisor phải tìm đúng số physical core rảnh cùng một lúc. Gán 8 vCPU cho ứng dụng chỉ dùng 2 thread? VMware vẫn chờ 8 core rảnh đồng thời — CPU scheduling delay tăng vọt.
Chỉ số cần theo dõi là CPU Ready Time — thời gian VM phải chờ được lên lịch chạy:
# SSH vào ESXi host và chạy esxtop
esxtop
# Nhấn 'c' để vào CPU view
# Cột %READY:
# < 5% = tốt
# 5-10% = chấp nhận được, cần monitor
# > 10% = có vấn đề, giảm vCPU hoặc migrate VM
# Export batch để phân tích:
esxtop -b -d 5 -n 12 > cpu_report.csvCấu hình mình áp dụng cho cluster 8 host:
- Web/App server: 2–4 vCPU
- Database server: 4–8 vCPU, nhưng phải theo CPU Ready sát sao
- Build server/CI: có thể nhiều hơn — workload batch, không cần latency thấp
RAM — để VM swap là mất hết hiệu suất
Rule mình nhắc team mỗi lần review hạ tầng: VMware swap file chậm hơn RAM vật lý hàng trăm lần. Khi host hết RAM, VMware swap page của VM ra disk — hiệu suất sụp đổ ngay lập tức, không có cách nào vá bằng cấu hình.
# Kiểm tra VM có đang swap không (từ bên trong Linux guest)
vmstat 1 5
# Cột 'si' (swap in) và 'so' (swap out) > 0 là dấu hiệu xấu
# Hoặc xem tổng quan nhanh
free -h
cat /proc/meminfo | grep -E 'SwapTotal|SwapFree|SwapCached'Khi host thiếu RAM, xử lý theo thứ tự: giảm RAM reservation của VM ít quan trọng trước → vMotion VM sang host còn bộ nhớ trống → mua thêm RAM vật lý. Theo thứ tự đó, không nhảy thẳng vào bước 3.
Nâng cao: Disk I/O và Snapshot
Noisy neighbor — thủ phạm thực sự của disk chậm
Bottleneck số 1 mình gặp trong production không phải CPU hay RAM, mà là disk I/O tranh chấp giữa các VM trên cùng datastore. Một VM đang backup hoặc rebuild index database lúc 2 giờ sáng kéo chậm cả chục VM còn lại trên cùng LUN — người dùng thấy web chậm lúc sáng sớm nhưng không ai biết tại sao.
# Kiểm tra disk latency trên ESXi (esxtop)
esxtop
# Nhấn 'd' để vào disk/storage view
# Cột DAVG (device average latency - ms):
# < 5ms = tốt
# 5-20ms = chấp nhận được
# > 20ms = có vấn đề nghiêm trọng, cần điều tra
# Cột KAVG: kernel latency — nếu cao, vấn đề ở hypervisor scheduling
# Cột GAVG = DAVG + KAVG: total latency từ góc nhìn VMVới VM database hoặc I/O intensive, ba thứ mình luôn áp dụng:
- Đặt trên datastore riêng, không chung với VM khác
- Dùng Thick Provision Eager Zeroed thay Thin Provision — tránh overhead zero-fill khi ghi lần đầu
- Bật Storage I/O Control (SIOC) ở cấp datastore để VMware tự cân bằng I/O giữa các VM
Snapshot chain dài — thứ giết hiệu suất chậm nhất
Mình tiếp nhận không ít hệ thống có snapshot chain 15–20 cái. Disk I/O chậm kinh khủng vì VMware phải đọc qua nhiều tầng delta file mỗi lần ghi. Worst case mình từng thấy: DAVG lên đến 80ms chỉ vì chain 18 snapshot tích lũy từ 8 tháng trước.
# Kiểm tra snapshot qua PowerCLI
Connect-VIServer -Server vcenter.company.local
Get-VM "TenVM" | Get-Snapshot | Select Name, Created, SizeGB | Format-Table
# Xem tất cả VM có snapshot trong cluster
Get-VM | Get-Snapshot | Select VM, Name, Created, SizeGB | Sort-Object SizeGB -DescendingSnapshot chỉ tạo trước khi patch hoặc upgrade, xóa ngay sau khi verify ổn. Dùng snapshot như backup dài hạn là sai mục đích — đó là việc của Veeam hoặc Nakivo.
Tips thực tế: Monitoring và CPU/RAM Reservation
Khi nào nên dùng Reservation
VMware cho phép set Reservation để đảm bảo tài nguyên tối thiểu cho VM. Mình chỉ set cho VM database production và real-time workload — thứ mà bị lấy tài nguyên là user thấy ngay lập tức.
Set Reservation tràn lan thì đừng. Nó khóa tài nguyên lại, DRS (Distributed Resource Scheduler) khó cân bằng tải giữa các host, và tổng capacity cluster tụt xuống trông thấy.
Cấu hình theo loại workload
Sau 6 tháng vận hành, mình chia VM thành 3 nhóm:
- Web/App server: VMXNET3 + PVSCSI + Thin Provision + 2–4 vCPU, không cần Reservation
- Database server: PVSCSI + Thick Eager Zeroed + RAM Reservation + theo balloon và swap liên tục
- Build server/CI: nhiều vCPU OK, Thin Provision OK, không cần Reservation — chịu được latency cao
Áp dụng đồng bộ những thứ này trên cluster 8 host ESXi: CPU ready time trung bình từ 8% xuống dưới 2%, disk latency ổn định dưới 5ms. Không phải phép màu — chỉ là chọn đúng driver, giữ snapshot ngắn, và nhìn vào đúng chỉ số. Nếu bạn đang vướng vấn đề cụ thể nào với VMware, cứ để lại comment — mình sẽ giải đáp dựa trên những gì đã thực sự gặp.
