Posted inVMware

VMware Paravirtual SCSI (PVSCSI): Giảm CPU Load Và Tăng Throughput Đĩa Cho Máy Ảo

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

Khi đĩa ảo trở thành cổ chai

Tháng trước mình vừa hoàn tất một đợt review toàn bộ storage layer trên cluster VMware vSphere 8.0 của công ty. Lý do là mấy VM chạy database (MySQL, PostgreSQL) liên tục báo I/O wait cao bất thường — nhìn vào CPU ready time thì ổn, RAM không thiếu, nhưng throughput đĩa chỉ đạt khoảng 60–70% so với benchmark lý thuyết của SAN.

Sau khi lần lượt loại trừ các yếu tố: datastore, HBA driver, RAID policy… mình phát hiện ra tất cả các VM đó đều đang dùng LSI Logic SAS adapter — mặc định khi tạo VM mới trong vSphere. Đây là adapter mô phỏng phần cứng thật, và đó chính là vấn đề.

Chuyển sang PVSCSI (Paravirtual SCSI) giải quyết được phần lớn. CPU I/O processing giảm xuống rõ rệt, throughput tăng lên đúng mức kỳ vọng. Bài viết này ghi lại quá trình đó — từ lý do kỹ thuật cho đến cách thực hiện và đo lường kết quả.

PVSCSI khác LSI Logic ở chỗ nào

LSI Logic SAS/BusLogic là adapter mô phỏng (emulated): VMkernel phải giả lập toàn bộ hành vi của một thiết bị phần cứng thật. Mỗi lệnh I/O từ guest OS đi qua một lớp emulation đầy overhead — interrupt simulation, register emulation, DMA mapping giả lập. Guest OS không cần driver đặc biệt vì nó “tưởng” mình đang giao tiếp với phần cứng thật.

PVSCSI là adapter paravirtualized: Guest OS biết mình đang chạy trên VMware và dùng driver đặc biệt để giao tiếp trực tiếp với VMkernel thông qua một giao thức tối ưu hóa. Không có emulation layer. I/O request đi thẳng vào VMkernel, giảm hẳn số CPU cycles tiêu tốn.

Theo benchmark VMware công bố, với workload I/O nặng:

  • CPU overhead giảm khoảng 30–50% cho workload I/O nặng
  • Throughput tăng lên đến 20–30% với sequential read/write
  • IOPS random 4K cải thiện 20–40% ở database workload tùy cấu hình storage

Tuy nhiên PVSCSI không phải lúc nào cũng vượt trội. VM ít I/O như web server tĩnh hay môi trường dev/test — sự khác biệt gần như không đáng kể. PVSCSI tỏa sáng ở những workload nặng: database server, file server, VM chạy CI/CD build pipeline liên tục.

Điều kiện để dùng PVSCSI

  • VMware vSphere 4.0 trở lên (hoặc VMware Workstation 6.5+)
  • Guest OS: RHEL/CentOS 5+, Ubuntu 10.04+, Windows Server 2003 SP2+ (với VMware Tools), Windows Vista+ (có driver built-in)
  • VMware Tools phải được cài đặt và cập nhật
  • Lưu ý quan trọng: Một số OS cũ như Windows Server 2003, RHEL 4 không có PVSCSI driver trong boot image — cần inject driver nếu dùng PVSCSI làm boot disk

Cấu hình PVSCSI — Từng bước thực tế

Cách 1: Đổi adapter qua vSphere Client (GUI)

Đây là cách nhanh nhất cho 1–2 VM. VM phải ở trạng thái Power Off hoàn toàn (không phải Suspend).

  1. Right-click VM → Edit Settings
  2. Click vào SCSI Controller 0 (hoặc adapter hiện tại)
  3. Dropdown Change Type → chọn VMware Paravirtual
  4. Nhấn OK → Power On VM

Boot xong, mở Device Manager trên Windows và tìm “VMware PVSCSI Controller” để xác nhận driver đã load đúng. Trên Linux thì lsmod | grep vmw_pvscsi là đủ.

Cách 2: Dùng PowerCLI để đổi hàng loạt VM

10+ VM mà làm tay thì mất cả buổi chiều. PowerCLI xử lý trong vài phút:

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

# Lấy danh sách VM cần đổi (ví dụ: tất cả VM trong folder "Production-DB")
$vms = Get-VM -Location (Get-Folder "Production-DB")

foreach ($vm in $vms) {
    # Bỏ qua VM đang chạy
    if ($vm.PowerState -ne "PoweredOff") {
        Write-Warning "$($vm.Name) đang chạy, bỏ qua..."
        continue
    }

    # Lấy SCSI controller chưa phải PVSCSI
    $scsiCtrl = Get-ScsiController -VM $vm | Where-Object { $_.Type -ne "ParaVirtualSCSI" }

    if ($scsiCtrl) {
        Write-Host "Đổi SCSI adapter của $($vm.Name)..."
        Set-ScsiController -ScsiController $scsiCtrl -Type ParaVirtualSCSI
        Write-Host "  Done: $($vm.Name)" -ForegroundColor Green
    } else {
        Write-Host "$($vm.Name) đã dùng PVSCSI, bỏ qua." -ForegroundColor Cyan
    }
}

Disconnect-VIServer -Confirm:$false

Một lưu ý thực tế: đừng power on hết một lần. Làm từng batch 3–5 VM, kiểm tra log và disk performance trước rồi mới tiếp — nếu có vấn đề driver, bạn biết ngay và chỉ cần rollback một nhóm nhỏ thay vì cả chục VM cùng lúc.

Cách 3: Chỉnh trực tiếp file .vmx (VMware Workstation / Fusion)

# Tìm file .vmx của VM
find ~/vmware -name "*.vmx" | grep "TenVM"

# Mở file và tìm dòng scsi0.virtualDev, đổi từ:
#   scsi0.virtualDev = "lsisas1068"
# Thành:
#   scsi0.virtualDev = "pvscsi"

sed -i 's/scsi0.virtualDev = "lsisas1068"/scsi0.virtualDev = "pvscsi"/' /path/to/vm.vmx

Sau đó mở VMware Workstation và power on VM như bình thường.

Kiểm tra sau khi đổi — trên Linux guest

# Kiểm tra driver PVSCSI đã load chưa
lsmod | grep vmw_pvscsi
# vmw_pvscsi            36864  4

# Xem thông tin disk controller
lspci | grep -i scsi
# VMware PVSCSI SCSI Controller

# Kiểm tra tốc độ đĩa cơ bản bằng dd
dd if=/dev/zero of=/tmp/test_io bs=1M count=1024 oflag=direct
# 1073741824 bytes (1.1 GB) copied, 2.84 s, 378 MB/s

Benchmark thực tế với fio

Để đo chính xác hơn, mình dùng fio — công cụ benchmark I/O tiêu chuẩn:

# Cài fio
apt install fio        # Ubuntu/Debian
yum install fio        # CentOS/RHEL

# Test 1: Sequential write (mô phỏng log writing, backup)
fio --name=seq-write \
    --ioengine=libaio \
    --rw=write \
    --bs=1M \
    --numjobs=4 \
    --size=2G \
    --runtime=60 \
    --group_reporting \
    --filename=/tmp/fio_test

# Test 2: Random 4K read (mô phỏng database IOPS)
fio --name=rand-read \
    --ioengine=libaio \
    --rw=randread \
    --bs=4k \
    --iodepth=64 \
    --numjobs=4 \
    --size=2G \
    --runtime=60 \
    --group_reporting \
    --filename=/tmp/fio_test

Kết quả so sánh thực tế từ một VM PostgreSQL (vSphere 8.0, NVMe datastore):

  • LSI Logic SAS: Random 4K Read ~85K IOPS, CPU I/O wait ~12%
  • PVSCSI: Random 4K Read ~118K IOPS, CPU I/O wait ~6%

CPU wait giảm từ 12% xuống 6% — đó là điều mình thấy ấn tượng nhất. Nửa số CPU cycles đó trước đây bị “nhốt” chờ I/O. Tài nguyên giải phóng ra, PostgreSQL có thêm chỗ để xử lý query thật sự.

Góc nhìn từ Proxmox — để hiểu PVSCSI sâu hơn

Khi migrate từ VMware sang Proxmox cho lab cá nhân, mình nhận thấy nhiều điểm khác biệt thú vị. Proxmox dùng VirtIO SCSI làm paravirtual adapter thay vì PVSCSI — cùng nguyên lý, khác implementation. Trên Proxmox, nếu không bật VirtIO thì disk performance cũng tệ y chang VMware với LSI Logic emulated.

Bài học rút ra: paravirtualization không phải “tính năng độc quyền VMware” mà là một kiến trúc tối ưu hóa I/O mà mọi hypervisor nghiêm túc đều phải implement. VMware gọi nó là PVSCSI, KVM/Proxmox gọi là VirtIO — bản chất giống nhau, đều giải quyết cùng một vấn đề overhead của emulation.

Những trường hợp không nên đổi PVSCSI

  • Boot disk trên OS cũ không có built-in driver: Windows Server 2003, RHEL 4 cần inject PVSCSI driver vào WinPE hoặc initramfs trước khi đổi boot disk. Nếu không quen làm việc này, giữ LSI Logic cho boot disk và chỉ đổi data disk sang PVSCSI.
  • VM test/dev ít I/O: Không đáng bỏ công downtime để đổi adapter nếu VM chỉ chạy web server tĩnh hay môi trường dev nhẹ.
  • Không có maintenance window: Đổi SCSI adapter bắt buộc phải Power Off VM hoàn toàn. Lên lịch rõ ràng và thông báo trước.

Kết luận

Mình thích PVSCSI ở chỗ này: không cần thêm phần cứng, không cần license mới, chỉ cần biết nó tồn tại và đổi một setting. Vậy mà nhiều môi trường production vẫn đang chạy LSI Logic vì “cài mặc định thế, không ai đổi”.

Nếu bạn đang quản lý cluster VMware với workload I/O cao (database, build server, NFS server chạy trong VM), audit SCSI adapter type là việc nên ưu tiên ngay. Downtime chỉ vài phút mỗi VM, nhưng cải thiện thấy ngay trên monitoring dashboard.

Một tip cuối: sau khi đổi PVSCSI, kiểm tra thêm queue depth. PVSCSI mặc định có queue depth cao hơn LSI Logic (256 so với 32 per device). Nếu datastore có giới hạn riêng, có thể cần tune thêm tham số Disk.SchedNumReqOutstanding trên ESXi host để tránh queue saturation và đảm bảo các VM khác trên cùng datastore không bị ảnh hưởng.

Share:
Tags: