Hướng dẫn thu hồi dung lượng lưu trữ (Space Reclamation / UNMAP) trên VMware ESXi - ITFROMZERO - Share tobe shared! Datastore VMware ESXi không giảm dung lượng dù máy ảo đã xóa hàng trăm GB? Hướng dẫn kỹ thuật thu hồi không gian lưu trữ (UNMAP / Space Reclamation) cho Thin VMDK chi tiết, an toàn.

Bạn vừa dọn sạch 300 GB database cũ trong máy ảo Windows, nhưng nhìn ra vSphere Client, ổ Datastore vẫn đỏ rực ở mức 92%? Dung lượng không nhả lại dù chỉ một megabyte. Đây là tình huống kinh điển mà bất cứ ai quản trị máy ảo dùng đĩa Thin Provisioning đều từng nếm trải.

Nguyên nhân bắt nguồn từ cơ chế xóa file của Guest OS. Khi bạn bấm xóa, hệ điều hành khách chỉ cập nhật lại bảng chỉ mục (MFT trên NTFS hoặc Inode trên ext4/xfs). Nó đánh dấu các block đó là “sẵn sàng ghi đè”, hoàn toàn không xóa trắng dữ liệu. Tầng hypervisor ESXi bên dưới không nhận được thông báo giải phóng này. Vì vậy, ESXi vẫn giữ nguyên dung lượng file VMDK. Theo thời gian, dung lượng ảo phình to liên tục và chiếm trọn không gian mảng SAN/NAS.

Hạ tầng bên mình chạy cụm 8 node ESXi với hơn 140 máy ảo kết nối mảng lưu trữ Dell Unity qua cáp quang SAN 16Gbps. Đợt bảo trì nào dọn dẹp dữ liệu lớn cũng phải chạy quy trình này để lấy lại hàng terabyte dung lượng lãng phí.

Table of Contents

Ba phương pháp thu hồi dung lượng phổ biến

Tùy theo hiện trạng máy ảo đang bật hay tắt và kiến trúc Datastore, bạn có 3 giải pháp chính:

Cách 1: Storage vMotion đổi định dạng đĩa — Chuyển máy ảo sang Datastore khác, đổi tạm sang Thick Eager Zeroed rồi chuyển ngược lại Thin.
Cách 2: Ghi số 0 (Zeroing) trong OS + co đĩa bằng vmkfstools — Chạy công cụ lấp số 0 vào vùng trống trong máy ảo, sau đó chạy lệnh punch zero ở tầng ESXi shell.
Cách 3: Chạy SCSI UNMAP (esxcli) hoặc cơ chế tự động VMFS-6 — Gửi lệnh SCSI UNMAP trả block trống từ Datastore về mảng lưu trữ SAN/NAS.

So sánh chi tiết ưu và nhược điểm

1. Storage vMotion

Ưu điểm: Thao tác 100% trên giao diện vCenter. Máy ảo chạy liên tục, không gây gián đoạn dịch vụ (Zero Downtime).
Nhược điểm: Cần Datastore thứ hai còn trống tối thiểu bằng kích thước máy ảo. Quá trình di chuyển ngốn băng thông storage network (thường đẩy throughput lên 300 – 500 MB/s).

2. Guest OS Zeroing kết hợp vmkfstools punch zero

Ưu điểm: Ép kích thước file -flat.vmdk co về sát dung lượng thực tế. Cực kỳ hiệu quả cho các máy ảo đơn lẻ vừa xóa dữ liệu lớn.
Nhược điểm: Phải tắt máy ảo (Downtime). Bước ghi số 0 ban đầu có thể đẩy IOPS của mảng đĩa lên cao và làm file VMDK tạm thời phình kịch khung dung lượng cấp phát.

3. Lệnh SCSI UNMAP (esxcli) và tính năng Auto UNMAP trên VMFS-6

Ưu điểm: Không cần tắt máy ảo. VMFS-6 tự động chạy ngầm theo cơ chế bất đồng bộ (Asynchronous Space Reclamation) với tốc độ điều tiết từ 25 MB/s đến 100 MB/s.
Nhược điểm: Chỉ thu hồi ở cấp độ Datastore (khi bạn xóa hẳn máy ảo hoặc xóa snapshot). Lệnh này không tự co nhỏ file VMDK nếu bên trong máy ảo chưa xử lý.

Nên dùng phương pháp nào trong thực tế?

Khi có thể sắp xếp lịch bảo trì (Downtime): Hãy dùng Cách 2. Đây là cách triệt để nhất để thu nhỏ file VMDK của một máy ảo cụ thể.
Hệ thống production 24/7 không được phép tắt: Tận dụng Storage vMotion nếu hạ tầng còn dư Datastore đệm.
Vừa xóa 5 – 10 máy ảo thử nghiệm nặng hàng trăm GB: Chạy lệnh esxcli storage vmfs unmap để mảng SAN/NAS cập nhật ngay số đo dung lượng khả dụng.

Quy trình triển khai từng bước

Bước 1: Làm sạch block rác từ bên trong máy ảo

Đầu tiên, chúng ta cần lấp đầy các vùng trống bằng số 0 để ESXi nhận biết được đâu là block rỗng.

Với Windows Server: Tải công cụ chính chủ SDelete từ Microsoft Sysinternals. Mở PowerShell dưới quyền Administrator:

# Tham số -z sẽ ghi số 0 vào toàn bộ vùng trống trên ổ C:
sdelete64.exe -z C:

Lưu ý: Trong lúc SDelete chạy, file VMDK sẽ phình to tối đa bằng mức dung lượng cấp phát (Provisioned Size). Đảm bảo Datastore còn đủ chỗ trước khi thực hiện.

Với Linux (RHEL, Ubuntu, Rocky Linux):

# Chạy lệnh fstrim để discard block trống (yêu cầu VM tương thích SCSI controller)
sudo fstrim -av

Nếu ổ đĩa không hỗ trợ TRIM trực tiếp, hãy tạo file rác toàn số 0 rồi xóa đi:

# Ghi số 0 vào file rác đến khi đầy ổ, sau đó xóa file
dd if=/dev/zero of=/var/tmp/zero.fill bs=1M status=progress; rm -f /var/tmp/zero.fill

Bước 2: Co nhỏ file VMDK bằng vmkfstools (Offline)

Tắt máy ảo cần xử lý. Mở SSH vào ESXi host chứa máy ảo và tìm đến thư mục lưu trữ:

# 1. Đi đến thư mục máy ảo
cd /vmfs/volumes/Datastore_SSD/AppServer01/

# 2. Kiểm tra snapshot (BẮT BUỘC KHÔNG ĐƯỢC CÓ SNAPSHOT)
ls -l *delta* *sesparse*

# 3. Chạy lệnh co đĩa (punch zero)
vmkfstools -K AppServer01.vmdk

Lệnh vmkfstools -K sẽ quét toàn bộ file đĩa. Chỗ nào chứa chuỗi số 0, ESXi sẽ cắt bỏ con trỏ metadata và giải phóng block vật lý. Một đĩa ảo 500 GB chứa 120 GB dữ liệu thực tế sẽ co lại đúng 120 GB trên Datastore.

Bước 3: Thu hồi dung lượng Datastore trả về SAN Storage (UNMAP)

Sau khi VMDK co lại hoặc bạn vừa xóa hẳn một máy ảo nặng, hãy thông báo cho mảng SAN giải phóng dung lượng cấp phát vật lý:

# Xem danh sách Datastore và lấy Volume UUID
esxcli storage filesystem list

# Chạy UNMAP với block count 200 để tránh nghẽn I/O mảng đĩa
esxcli storage vmfs unmap -u 652a9f14-38b81234-5678-001b21xxxxxx -b 200

Mỗi block tương đương 1 MB. Tùy chọn -b 200 ép lệnh xử lý từng đợt 200 MB một, giữ an toàn cho hàng đợi I/O của hệ thống SAN đang chạy song song.

Ba nguyên tắc sống còn tránh rủi ro

Xóa sạch Snapshot trước khi chạy vmkfstools: Lệnh vmkfstools -K chạy trên đĩa gốc khi còn snapshot delta có nguy cơ làm hỏng toàn bộ chuỗi đĩa (snapshot chain).
Không chỉnh block count (-b) quá cao: Đặt giá trị lớn hơn 500 có thể khiến mảng SAN bị nghẽn queue depth, làm tăng latency của toàn bộ các máy ảo khác trên cùng LUN.
Ưu tiên chuẩn VMFS-6: Luôn định dạng Datastore mới bằng VMFS-6 để cơ chế UNMAP tự động kích hoạt ngầm, đỡ mất công chạy lệnh thủ công vào ban đêm.