VMware [Module 8]: Quản lý VM – vMotion, Storage vMotion, Snapshots, kiểm soát tài nguyên

Nội dung bao gồm 7 phần:
1. vSphere vMotion
2. Enhanced vMotion Compatibility (EVC)
3. vSphere Storage vMotion
4. Cross vCenter Migrations
5. VM Snapshots
6. Virtual CPU and Memory Concepts
7. Resource Controls

I. vSPHERE vMOTION​

I.1. Các loại Migration​

vSphere cung cấp hai phương thức di chuyển máy ảo (migration) chính:

• Cold Migration: Di chuyển máy ảo đang tắt hoặc đang treo (suspended). Phương thức này đơn giản vì không cần chuyển trạng thái bộ nhớ đang hoạt động. Máy ảo sẽ bị ngắt kết nối khỏi host nguồn, các file được sao chép sang đích, và máy ảo được đăng ký tại host đích.

• Hot Migration (vMotion): Di chuyển máy ảo đang chạy giữa các host mà không gây gián đoạn dịch vụ . Toàn bộ trạng thái máy ảo – bộ nhớ, định nghĩa, nhận diện (identification) – được chuyển sang host đích trong khi storage vẫn giữ nguyên vị trí.

Migrate Wizard trong vSphere Client cung cấp các tuỳ chọn:
- Change compute resource only: Chỉ chuyển máy ảo sang host/cluster khác (vMotion)
- Change storage only: Chỉ chuyển file máy ảo sang datastore khác (Storage vMotion)
- Change both compute resource and storage: Chuyển đồng thời cả host và storage
- Cross vCenter Server export: Xuất máy ảo sang hệ thống vCenter Server khác

I.2. Khả năng của vMotion​

vMotion mang lại nhiều lợi ích quan trọng trong vận hành datacenter:

• Tối ưu hoá sử dụng phần cứng: Phân bổ lại workload giữa các host để tận dụng tài nguyên hiệu quả hơn.

• Bảo trì không ngừng hoạt động: Di chuyển toàn bộ máy ảo ra khỏi host trước khi thực hiện bảo trì phần cứng, cập nhật firmware, hoặc vá lỗi ESXi mà không ảnh hưởng đến người dùng cuối.

• Cân bằng tải DRS (Distributed Resource Scheduler): DRS tự động sử dụng vMotion để di chuyển máy ảo giữa các host trong cluster nhằm cân bằng tải CPU và bộ nhớ.

Khi thực hiện vMotion, toàn bộ trạng thái máy ảo được di chuyển bao gồm: trạng thái bộ nhớ, định nghĩa máy ảo (VM definition – file cấu hình, BIOS/EFI, device state), và thông tin nhận diện (identification – MAC address, UUID). Storage của máy ảo không bị di chuyển – nó vẫn nằm trên shared storage mà cả host nguồn và đích đều truy cập được.

I.3. Cấu hình VMkernel Adapter cho vMotion​

Để vMotion hoạt động, cần có VMkernel adapter được bật dịch vụ vMotion trên cả host nguồn và host đích. VMkernel adapter là giao diện mạng ảo dành riêng cho lưu lượng VMkernel (management, vMotion, vSAN, NFS, v.v.).

Cấu hình bao gồm:
- Tạo VMkernel port group trên vSwitch (Standard hoặc Distributed)
- Gán địa chỉ IP cho VMkernel adapter
- Bật tuỳ chọn "vMotion" trong phần Enabled Services
- Đảm bảo cả host nguồn và đích đều có VMkernel adapter vMotion trên cùng VLAN/subnet hoặc có thể định tuyến đến nhau

Khuyến nghị sử dụng ít nhất 2 VMkernel port dành cho vMotion để tăng băng thông và khả năng chịu lỗi. Khi có nhiều VMkernel port vMotion, lưu lượng sẽ được phân tải tự động.

I.4. Quy trình vMotion – 7 bước​

Quá trình vMotion diễn ra theo 7 bước tuần tự:

Bước 1 – Tạo Shadow VM: Một bản sao rỗng của máy ảo được tạo trên host đích. Shadow VM được đăng ký với vCenter Server nhưng chưa có dữ liệu bộ nhớ.

Bước 2 – Sao chép bộ nhớ lặp lại: Toàn bộ bộ nhớ của máy ảo được sao chép từ host nguồn sang host đích qua mạng vMotion. Trong lần sao chép đầu, toàn bộ bộ nhớ được gửi đi. Trong các lần lặp tiếp theo, chỉ các trang bộ nhớ bị thay đổi kể từ lần sao chép trước được gửi lại. Quá trình lặp này tiếp tục cho đến khi lượng dữ liệu thay đổi đủ nhỏ.

Bước 3 – Tạm ngưng: Khi lượng bộ nhớ thay đổi còn dưới ngưỡng (thường < 500 mili giây để truyền), máy ảo bị tạm ngưng cực ngắn trên host nguồn. Đây là khoảng "switchover" không thể tránh khỏi nhưng rất ngắn (thường < 1 giây, người dùng không nhận thấy).

Bước 4 – Chuyển trạng thái thiết bị và bitmap: Trạng thái thiết bị của máy ảo cùng với bitmap ghi nhận các trang bộ nhớ thay đổi cuối cùng được gửi từ host nguồn sang host đích.

Bước 5 – Khởi động trên host đích + GARP: Máy ảo được kích hoạt trên host đích. Ngay lập tức, host đích phát Gratuitous ARP (GARP) để thông báo cho switch vật lý rằng MAC address của máy ảo giờ đã nằm trên port mới, đảm bảo lưu lượng mạng được chuyển hướng đúng.

Bước 6 – Chuyển quyền truy cập người dùng: Toàn bộ kết nối mạng của người dùng cuối được chuyển sang host đích. Máy ảo tiếp tục hoạt động bình thường trên host mới mà không mất kết nối.

Bước 7 – Giải phóng bộ nhớ nguồn: Bộ nhớ của máy ảo trên host nguồn được giải phóng hoàn toàn, kết thúc quá trình vMotion.

I.5. Yêu cầu đối với Máy ảo​

Để thực hiện vMotion, máy ảo cần đáp ứng các yêu cầu sau:

• Nếu máy ảo sử dụng RDM (Raw Device Mapping), LUN RDM phải có thể truy cập được từ host đích.

• Máy ảo không được mount CD/DVD image từ local storage của host nguồn. Nếu có ISO image gắn vào ổ CD/DVD ảo, ISO đó phải nằm trên shared storage hoặc phải được ngắt kết nối trước khi thực hiện vMotion.

• Các thiết bị passthrough (như USB, PCI) có thể gây cản trở vMotion trừ khi được cấu hình đặc biệt.

I.6. Yêu cầu đối với Host​

Các yêu cầu về host để vMotion hoạt động:

• Shared Storage: Cả host nguồn và đích phải cùng truy cập được shared storage chứa file máy ảo. Hỗ trợ tối đa 128 hoạt động migration đồng thời trên mỗi datastore.

• VMkernel vMotion port: Cả hai host phải có VMkernel adapter được bật dịch vụ vMotion.

• Matching IP families: VMkernel adapter vMotion trên cả hai host phải sử dụng cùng loại địa chỉ IP (cùng IPv4 hoặc cùng IPv6).

• Swap file: Xem xét vị trí swap file (.vswp) của máy ảo. Nếu swap file nằm trên local storage của host nguồn, nó sẽ cần được di chuyển hoặc tạo mới trên host đích.

• CPU Compatibility: CPU của host đích phải tương thích với CPU của host nguồn (cùng vendor, cùng generation hoặc sử dụng EVC). Nếu không, máy ảo có thể gặp lỗi khi chạy các instruction không được hỗ trợ trên CPU đích.

I.7. Giới hạn đồng thời và Băng thông​

vMotion yêu cầu băng thông tối thiểu 250 Mbps cho mỗi hoạt động migration. Số lượng migration đồng thời phụ thuộc vào tốc độ NIC:

• NIC 1 Gbps: Tối đa 4 vMotion đồng thời
• NIC 10 Gbps trở lên: Tối đa 8 vMotion đồng thời

Khuyến nghị: Sử dụng ít nhất 2 VMkernel port dành cho vMotion. Khi có nhiều port, vMotion tự động sử dụng cả hai để tăng throughput. Với mạng 10 Gbps, hiệu suất vMotion được cải thiện đáng kể, cho phép di chuyển máy ảo có bộ nhớ lớn nhanh hơn nhiều.

I.8. Encrypted vMotion​

vSphere cung cấp ba mức độ mã hoá cho vMotion:

• Disabled: Không mã hoá lưu lượng vMotion. Dữ liệu bộ nhớ truyền dạng cleartext.

• Opportunistic (mặc định): Sử dụng mã hoá nếu cả host nguồn và đích đều hỗ trợ. Nếu một trong hai không hỗ trợ, vMotion vẫn tiến hành nhưng không mã hoá.

• Required: Bắt buộc mã hoá. Nếu host đích không hỗ trợ encrypted vMotion, migration sẽ thất bại.

Lưu ý quan trọng:
- Đối với máy ảo đã được mã hoá , encrypted vMotion tự động được bật bất kể cài đặt.
- Encrypted vMotion hỗ trợ tất cả các biến thể vMotion (vMotion, cross-host, cross-cluster, cross-vCenter).
- Encrypted vMotion không hỗ trợ encrypted Storage vMotion. Storage vMotion là quy trình riêng biệt và không sử dụng cùng cơ chế mã hoá truyền tải.

II. ENHANCED vMOTION COMPATIBILITY (EVC)​

II.1. Ràng buộc CPU đối với vMotion​

Khi thực hiện vMotion, tương thích CPU giữa host nguồn và đích là yếu tố then chốt. Có hai nhóm thuộc tính CPU cần xem xét:

Các thuộc tính không cần khớp (được ảo hoá bởi VMkernel):
- Tốc độ xung nhịp (clock speed)
- Dung lượng cache
- Số lõi (number of cores)
Những thuộc tính này được VMkernel ảo hoá nên không gây vấn đề tương thích.

Các thuộc tính bắt buộc phải khớp:
- Nhà sản xuất CPU: Intel với Intel, AMD với AMD. Không thể vMotion giữa Intel và AMD.
- Họ CPU và thế hệ: CPU phải cùng họ hoặc tương thích. Ví dụ: không thể vMotion trực tiếp từ Intel Skylake sang Intel Broadwell nếu máy ảo sử dụng instruction mới.
- Tập lệnh mở rộng: SSE3, SSSE3, SSE4.1 phải khớp. Nếu máy ảo đang sử dụng instruction SSE4.1 và host đích không hỗ trợ, vMotion sẽ thất bại.

II.2. EVC là gì?​

Enhanced vMotion Compatibility (EVC) là tính năng ở cấp cluster, cho phép tạo "CPU baseline" – một mức chuẩn CPU tối thiểu cho toàn bộ cluster. EVC hoạt động bằng cách che giấu các tính năng CPU mới hơn baseline, đảm bảo tất cả máy ảo chỉ "nhìn thấy" tập lệnh CPU tương thích với baseline đã chọn.

Ví dụ: Nếu cluster có EVC baseline là "Intel Haswell Generation", tất cả host (kể cả những host có CPU Skylake) sẽ chỉ expose tập lệnh CPU tương đương Haswell cho máy ảo. Điều này cho phép vMotion tự do giữa các host trong cluster bất kể thế hệ CPU thực tế.

EVC tự động cấu hình CPUID masking – quản trị viên chỉ cần chọn baseline mong muốn.

II.3. Yêu cầu Cluster cho EVC​

Để bật EVC trên cluster, cần đáp ứng các yêu cầu:

• Cùng vendor CPU: Tất cả host trong cluster phải sử dụng cùng nhà sản xuất CPU (tất cả Intel hoặc tất cả AMD). Không thể trộn lẫn.

• Hardware Virtualization: CPU phải hỗ trợ công nghệ ảo hoá phần cứng – AMD-V (đối với AMD) hoặc Intel VT (đối với Intel). Tính năng này phải được bật trong BIOS.

• Execution-Disable bit: CPU phải hỗ trợ tính năng NX (No Execute) trên AMD hoặc XD (Execute Disable) trên Intel. Đây là tính năng bảo mật ngăn thực thi mã trên vùng bộ nhớ dữ liệu.

• vMotion đã cấu hình: Tất cả host phải có VMkernel adapter vMotion được cấu hình đúng.

II.4. Cấu hình EVC​

Có hai cách bật EVC:

1) Cluster rỗng: Tạo cluster mới, bật EVC và chọn baseline trước khi thêm host. Đây là cách đơn giản nhất.

2) Cluster đã có host: Phải đưa tất cả host vào chế độ Maintenance Mode trước khi bật EVC. Điều này có nghĩa tất cả máy ảo phải được di chuyển ra khỏi host hoặc tắt.

Nâng cấp EVC:
- Có thể nâng baseline lên thế hệ CPU mới hơn mà không cần tắt máy ảo.
- Máy ảo đang chạy sẽ không thấy tính năng CPU mới ngay lập tức.
- Các tính năng CPU mới chỉ có hiệu lực sau khi máy ảo được power cycle (tắt rồi bật lại, không chỉ restart guest OS).

Hạ cấp EVC:
- Bắt buộc phải tắt tất cả máy ảo trong cluster trước khi hạ baseline.
- Không thể hạ EVC khi có máy ảo đang chạy vì chúng có thể đang sử dụng instruction không có trong baseline thấp hơn.

II.5. Per-VM EVC​

Ngoài EVC ở cấp cluster, vSphere còn hỗ trợ Per-VM EVC – thuộc tính gắn với từng máy ảo riêng biệt.

Đặc điểm của Per-VM EVC:
- Là thuộc tính của máy ảo, không phải của cluster.
- Tồn tại bền vững qua các lần migration và power cycle.
- Hoạt động độc lập với EVC cluster – máy ảo có thể có Per-VM EVC khác với baseline cluster.
- Cho phép di chuyển máy ảo giữa các datacenter khác nhau, thậm chí giữa các cluster không bật EVC, miễn là host đích có CPU hỗ trợ baseline Per-VM EVC.

Per-VM EVC đặc biệt hữu ích khi:
- Cần di chuyển máy ảo giữa các cluster có EVC baseline khác nhau
- Muốn kiểm soát tương thích CPU ở mức từng máy ảo
- Thực hiện migration cross-datacenter hoặc cross-vCenter

II.6. EVC cho vSGA GPU​

vSphere mở rộng khái niệm EVC sang GPU cho trường hợp sử dụng vSGA (virtual Shared Graphics Acceleration).

- GPU feature baseline: Tương tự CPU baseline, định nghĩa tập tính năng GPU tối thiểu cho cluster.
- Hỗ trợ cả ở cấp cluster và cấp per-VM.
- Đảm bảo máy ảo sử dụng vSGA có thể vMotion giữa các host có GPU khác nhau (nhưng cùng vendor) trong cluster mà không gây lỗi đồ hoạ.

III. vSPHERE STORAGE vMOTION​

III.1. Tổng quan Storage vMotion​

Storage vMotion cho phép di chuyển file của máy ảo đang chạy từ datastore này sang datastore khác mà không gây gián đoạn. Máy ảo vẫn tiếp tục chạy trên cùng host – chỉ storage thay đổi vị trí.

Storage vMotion hỗ trợ di chuyển giữa các loại datastore khác nhau: VMFS sang NFS, NFS sang VMFS, VMFS sang VMFS, v.v.

III.2. Các trường hợp sử dụng​

• Bảo trì storage array: Di chuyển máy ảo ra khỏi array trước khi nâng cấp firmware, thay ổ đĩa, hoặc decommission array cũ.

• Thay đổi loại disk provisioning: Chuyển đổi giữa thick provisioned (lazy zeroed, eager zeroed) và thin provisioned. Ví dụ: chuyển từ thin sang thick eager zeroed để cải thiện hiệu suất I/O.

• Cân bằng tải storage: Phân bổ lại máy ảo giữa các datastore để tránh tình trạng một datastore quá tải về dung lượng hoặc IOPS.

• Đổi tên file khớp inventory: Khi đổi tên máy ảo trong vCenter, tên thư mục và file trên datastore không tự động thay đổi. Storage vMotion tạo lại file với tên khớp tên máy ảo hiện tại.

III.3. Quy trình I/O Mirroring – 5 bước​

Storage vMotion sử dụng kỹ thuật I/O Mirroring để đảm bảo dữ liệu nhất quán:

Bước 1 – Khởi tạo (Initiate): vCenter Server nhận yêu cầu Storage vMotion, xác minh tài nguyên trên datastore đích và bắt đầu quy trình.

Bước 2 – Sao chép dữ liệu (Copy Data): Dữ liệu đĩa ảo được sao chép từ datastore nguồn sang datastore đích. Quá trình này sử dụng VMkernel data mover hoặc VAAI (vStorage API for Array Integration) nếu được hỗ trợ. Đây là bước single-pass – chỉ sao chép một lần, không lặp lại nhiều lần.

Bước 3 – Tạo tiến trình VM mới (New VM Process): Một tiến trình VM mới được tạo trên host, trỏ đến vị trí storage mới.

Bước 4 – Phản chiếu I/O (Mirror I/O): Mirror driver được kích hoạt. Tất cả các lệnh ghi từ máy ảo được đồng bộ phản chiếu sang cả datastore nguồn và đích. Điều này đảm bảo cả hai bản sao luôn đồng nhất trong suốt quá trình chuyển đổi.

Bước 5 – Chuyển đổi (Transition): Khi dữ liệu đã đồng bộ hoàn toàn, tiến trình VM cũ bị ngắt và tiến trình mới (trỏ đến storage đích) tiếp quản. File trên datastore nguồn được dọn dẹp.

III.4. VAAI – vStorage API for Array Integration​

VAAI cho phép "offload" (chuyển gánh nặng) hoạt động sao chép dữ liệu từ host ESXi sang storage array. Điều kiện sử dụng VAAI trong Storage vMotion:

- Storage array phải hỗ trợ VAAI (hầu hết SAN array enterprise đều hỗ trợ)
- Cả datastore nguồn và đích phải nằm trên CÙNG một storage array

Khi VAAI được sử dụng, quá trình sao chép diễn ra nội bộ trong array, giảm đáng kể tải cho host ESXi và mạng storage.

III.5. Hướng dẫn và hạn chế​

Hướng dẫn:
- Phối hợp với quản trị viên storage trước khi thực hiện Storage vMotion quy mô lớn
- Thực hiện ngoài giờ cao điểm để giảm ảnh hưởng đến I/O production

Hạn chế:
- Đĩa ảo độc lập phải ở chế độ persistent mode mới thực hiện Storage vMotion được. Independent disk ở chế độ nonpersistent không hỗ trợ Storage vMotion.

Di chuyển kết hợp Compute + Storage:
- vSphere cho phép thực hiện đồng thời cả vMotion và Storage vMotion trong một thao tác duy nhất.
- Hoạt động này có thể vượt qua ranh giới cluster, datacenter, thậm chí vCenter Server instance khác nhau.

IV. CROSS vCENTER MIGRATIONS​

IV.1. Các trường hợp sử dụng​

• Cân bằng workload giữa các vCenter: Phân bổ lại máy ảo giữa các hệ thống vCenter khác nhau để tối ưu tài nguyên.

• Dev-to-Prod migration: Di chuyển máy ảo từ môi trường phát triển sang production khi sẵn sàng triển khai.

• Thay đổi SLA: Di chuyển workload giữa các tier dịch vụ khác nhau (ví dụ: từ standard sang premium tier với SLA cao hơn).

• On-premises to Cloud: Di chuyển máy ảo từ datacenter on-premises lên VMware Cloud on AWS (VMC on AWS) hoặc các dịch vụ hybrid cloud khác.

IV.2. Yêu cầu​

• Đồng bộ thời gian: Tất cả vCenter Server và ESXi host phải được đồng bộ thời gian (qua NTP). Sai lệch thời gian có thể gây lỗi xác thực.

• SSO Domain: Có thể cùng hoặc khác SSO domain. Không yêu cầu Enhanced Linked Mode (ELM).

• Storage access: Đối với migration chỉ chuyển compute, host đích phải có quyền truy cập vào storage chứa file máy ảo. Đối với migration kèm storage, điều kiện này không bắt buộc.

IV.3. Migration trong cùng SSO Domain​

Khi cả vCenter nguồn và đích thuộc cùng một SSO domain:
- Quản trị viên có thể trực tiếp chọn tài nguyên compute (host, cluster, resource pool) trên vCenter đích trong Migrate Wizard.
- Không cần nhập thông tin đăng nhập bổ sung vì đã xác thực qua SSO chung.
- Giao diện hiển thị tất cả tài nguyên từ cả hai vCenter nếu đã cấu hình Enhanced Linked Mode.

IV.4. Migration giữa các SSO Domain khác nhau​

Khi vCenter nguồn và đích thuộc SSO domain khác nhau:
- Sử dụng tuỳ chọn "Cross vCenter Server export" trong Migrate Wizard.
- Cần chỉ định FQDN (Fully Qualified Domain Name) của vCenter Server đích.
- Cần cung cấp thông tin đăng nhập có quyền phù hợp trên vCenter đích.
- Quá trình xuất sẽ hủy đăng ký máy ảo khỏi vCenter nguồn và đăng ký trên vCenter đích.

IV.5. Kiểm tra Network​

Khi thực hiện cross-vCenter migration, các vấn đề network cần được kiểm tra:

• MAC address compatibility: Đảm bảo MAC address của máy ảo không xung đột với các máy ảo khác trên host/network đích.

• Distributed → Standard switch: vSphere ngăn cản migration từ distributed switch sang standard switch vì standard switch không hỗ trợ các tính năng network policy nâng cao.

• Switch version mismatch: Kiểm tra phiên bản distributed switch giữa nguồn và đích. Phiên bản không khớp có thể gây cảnh báo hoặc lỗi.

IV.6. TCP/IP Stacks​

vSphere cung cấp nhiều TCP/IP stack cho các mục đích khác nhau:

• Default stack: Stack mặc định, dùng cho management traffic và các dịch vụ không có stack riêng.

• vMotion stack: Dành riêng cho lưu lượng vMotion. Cho phép cấu hình default gateway riêng biệt cho traffic vMotion.

• Provisioning stack (NFC – Network File Copy): Dùng cho lưu lượng provisioning, bao gồm cold migration, cloning, và snapshot. Đặc biệt hữu ích cho long-distance migration vì NFC traffic có thể định tuyến qua mạng WAN riêng.

• Custom stack: Stack tuỳ chỉnh do quản trị viên tạo cho các mục đích đặc biệt.

IV.7. Long-Distance vMotion​

vSphere hỗ trợ vMotion qua khoảng cách xa (long-distance) với các đặc điểm:

• Kết nối L3 (Layer 3): Hỗ trợ định tuyến qua nhiều subnet, không yêu cầu L2 adjacency. Sử dụng vMotion TCP/IP stack với gateway riêng.

• Băng thông tối thiểu: 250 Mbps cho mỗi hoạt động vMotion.

• RTT tối đa: Round-Trip Time lên đến 150 mili giây. Đây là mức latency phù hợp cho kết nối giữa các datacenter cách xa hàng trăm km.

• Follow-the-Sun scenario: Một trường hợp sử dụng phổ biến – di chuyển workload giữa các datacenter ở múi giờ khác nhau để phục vụ người dùng ở khu vực đang trong giờ làm việc, tận dụng tối đa tài nguyên và giảm latency cho người dùng cuối.

V. VM SNAPSHOTS​

V.1. Tổng quan Snapshot​

Snapshot lưu giữ trạng thái của máy ảo tại một thời điểm cụ thể. Có thể tạo snapshot khi máy ảo đang bật, tắt hoặc treo.

QUAN TRỌNG: Snapshot không phải là giải pháp backup. Snapshot phụ thuộc vào base disk – nếu base disk bị hỏng, snapshot cũng mất. Snapshot nên được sử dụng tạm thời (trước khi cập nhật, thử nghiệm) và xoá sau khi hoàn tất.

V.2. Snapshot lưu giữ những gì?​

Khi tạo snapshot, các thành phần sau được lưu:

• Cấu hình máy ảo: File .vmx chứa cấu hình phần cứng ảo tại thời điểm snapshot.

• Trạng thái bộ nhớ: Tuỳ chọn, chỉ khả dụng khi máy ảo đang bật. Nếu bật, toàn bộ nội dung RAM được lưu vào file .vmem. Khi revert, máy ảo sẽ trở lại đúng trạng thái đang chạy.

• Trạng thái đĩa ảo: Từ thời điểm snapshot, tất cả ghi mới không ảnh hưởng đến base disk mà được ghi vào delta disk riêng.

Snapshot không lưu giữ:
- Independent disks: Đĩa ảo ở chế độ independent (persistent hoặc nonpersistent) bị loại trừ khỏi snapshot.

V.3. Tuỳ chọn Quiesce​

Quiesce (đồng bộ hệ thống file guest): Khi bật tuỳ chọn này, VMware Tools yêu cầu guest OS flush toàn bộ dữ liệu đang chờ trong bộ đệm ra đĩa, đảm bảo hệ thống file trong trạng thái nhất quán tại thời điểm snapshot.

Lưu ý: Tuỳ chọn Quiesce và Memory snapshot loại trừ lẫn nhau. Không thể vừa lưu trạng thái bộ nhớ vừa quiesce guest file system trong cùng một snapshot. Nếu chọn Memory snapshot, Quiesce bị vô hiệu và ngược lại.

V.4. Các loại Delta Disk​

Khi tạo snapshot, delta disk được tạo để ghi nhận các thay đổi. vSphere sử dụng các loại delta disk khác nhau:

• VMFSsparse:
- Sử dụng trên VMFS5
- Áp dụng cho đĩa có kích thước < 2 TB
- Kích thước block: 512 byte
- Tên file: <vmname>-delta.vmdk
- Là loại delta disk truyền thống, có overhead cao hơn so với SEsparse

• SEsparse (Space Efficient sparse):
- Mặc định trên VMFS6; trên VMFS5 chỉ dùng cho đĩa ≥ 2 TB
- Kích thước block: 4 KB
- Tên file: <vmname>-sesparse.vmdk
- Tiết kiệm không gian hơn
- Hỗ trợ UNMAP: Khi guest OS xoá dữ liệu, không gian có thể được thu hồi trên datastore

• vsanSparse:
- Sử dụng trên vSAN datastore
- Kích thước block: 4 MB
- Được tối ưu cho kiến trúc phân tán của vSAN

V.5. Các file Snapshot​

Một snapshot tạo ra nhiều file trên datastore:

• .vmsn – Lưu trạng thái cấu hình của máy ảo tại thời điểm snapshot.

• .vmem – Lưu nội dung bộ nhớ nếu tuỳ chọn Memory snapshot được bật. File này có kích thước bằng dung lượng RAM cấu hình của máy ảo.

• -00000#.vmdk – File descriptor cho delta disk, chứa metadata về snapshot (parent disk, CID, v.v.). Số # tăng dần (000001, 000002, ...) cho mỗi snapshot.

• Delta disk data file – File dữ liệu thực chứa các block thay đổi kể từ snapshot.

• .vmsd – File XML chứa danh sách tất cả snapshot và mối quan hệ parent-child giữa chúng. File này được cập nhật mỗi khi tạo hoặc xoá snapshot.

V.6. Quản lý Snapshot​

Snapshot Manager trong vSphere Client cung cấp các thao tác:

• Edit: Thay đổi tên và mô tả của snapshot.

• Delete: Hợp nhất dữ liệu delta disk vào parent disk. QUAN TRỌNG: Trạng thái hiện tại của máy ảo không thay đổi – máy ảo vẫn tiếp tục chạy với dữ liệu hiện tại. Delete chỉ loại bỏ snapshot point và hợp nhất dữ liệu.

• Delete All: Hợp nhất tất cả delta disk về base disk gốc. Tương tự Delete nhưng áp dụng cho toàn bộ chuỗi snapshot.

• Revert : Đưa máy ảo trở lại trạng thái của snapshot được chọn. CẢNH BÁO: Tất cả thay đổi sau thời điểm snapshot sẽ bị mất hoàn toàn. Nếu không tạo snapshot của trạng thái hiện tại trước khi Revert, dữ liệu mới không thể khôi phục.

V.7. Consolidation​

Trong một số trường hợp, quá trình Delete snapshot hợp nhất thành công metadata (descriptor file .vmdk) nhưng delta disk data file vẫn còn tồn tại trên datastore. Tình trạng này gọi là cần Consolidation.

Khi cần consolidation:
- vSphere hiển thị cảnh báo trong tab Monitor > All Issues
- Thông báo: "Virtual machine disks consolidation is needed"
- Quản trị viên cần thực hiện "Consolidate" thủ công từ menu chuột phải trên máy ảo

Consolidation hợp nhất các delta file còn sót vào base disk, giải phóng không gian datastore và đảm bảo chuỗi disk nhất quán.

VI. VIRTUAL CPU VÀ MEMORY CONCEPTS​

VI.1. Ảo hoá Bộ nhớ – 3 tầng​

Ảo hoá bộ nhớ trong vSphere bao gồm 3 tầng chuyển đổi địa chỉ:

Tầng 1 – Guest OS Virtual Memory: Guest OS quản lý không gian địa chỉ ảo cho các process/application. Guest OS sử dụng page table để ánh xạ địa chỉ ảo sang địa chỉ vật lý (từ góc nhìn của guest).

Tầng 2 – Guest OS Physical Memory: Đây là bộ nhớ vật lý mà guest OS nhìn thấy, nhưng thực tế là bộ nhớ ảo do VMkernel quản lý. Guest OS nghĩ rằng nó có RAM vật lý liên tục, nhưng VMkernel ánh xạ các "physical page" này vào machine memory thực sự.

Tầng 3 – Host Machine Memory: RAM vật lý thực sự trên host ESXi. VMkernel quản lý ánh xạ từ guest physical memory sang machine memory thông qua cấu trúc shadow page table hoặc EPT/RVI (Extended Page Tables / Rapid Virtualization Indexing).

VMkernel thêm tầng chuyển đổi địa chỉ (address translation) giữa guest physical và host machine memory, cho phép nhiều máy ảo chia sẻ RAM vật lý một cách an toàn và hiệu quả.

VI.2. Memory Overcommitment​

Overcommitment xảy ra khi tổng bộ nhớ cấu hình cho tất cả máy ảo vượt quá RAM vật lý của host. Ví dụ: host có 64 GB RAM nhưng tổng bộ nhớ cấu hình các máy ảo là 80 GB.

Overcommitment không phải lúc nào cũng gây vấn đề. Trong thực tế, nhiều máy ảo không sử dụng hết bộ nhớ được cấp – một phần RAM ở trạng thái nhàn rỗi (idle). VMkernel tận dụng điều này để cho phép chạy nhiều máy ảo hơn trên cùng một host.

Tuy nhiên, khi nhu cầu bộ nhớ thực tế tăng cao và vượt quá RAM vật lý, VMkernel phải sử dụng các kỹ thuật thu hồi bộ nhớ.

VI.3. 5 Kỹ thuật xử lý Overcommitment (theo thứ tự ưu tiên)​

VMkernel sử dụng 5 kỹ thuật theo thứ tự ưu tiên từ tốt nhất đến xấu nhất:

1) Transparent Page Sharing (TPS):
- Chia sẻ các trang bộ nhớ có nội dung giống hệt nhau. VMkernel phát hiện các page trùng lặp bằng hash, chỉ giữ một bản gốc trong machine memory và ánh xạ nhiều guest page vào cùng bản đó.
- Kể từ vSphere 6.0, TPS chỉ hoạt động trong phạm vi từng máy ảo (within-VM only, còn gọi là intra-VM TPS) để đảm bảo bảo mật. TPS liên máy ảo bị tắt mặc định do rủi ro tấn công side-channel.
- Hiệu quả nhất khi máy ảo chạy cùng OS và ứng dụng (nhiều page giống nhau).

2) Ballooning (Memory Balloon Driver – vmmemctl):
- Sử dụng driver vmmemctl được cài đặt cùng VMware Tools trong guest OS.
- Khi VMkernel cần thu hồi bộ nhớ, balloon driver phồng lên trong guest OS, yêu cầu guest OS cấp thêm bộ nhớ cho driver. Guest OS tự quyết định trang nào ít giá trị nhất để nhường – thường sẽ swap những trang đó ra guest swap file.
- VMkernel sau đó thu hồi machine memory mà balloon driver chiếm.
- Ưu điểm: Guest OS tự quản lý việc nhường bộ nhớ, chọn trang tối ưu. Hiệu quả hơn host-level swap.
- Yêu cầu: VMware Tools phải được cài đặt; guest OS cần có swap file/partition đủ lớn.

3) Memory Compression:
- Trước khi swap page ra đĩa, VMkernel thử nén page đó.
- Nếu nén được xuống ≤ 50% kích thước gốc, page được lưu trong vùng compression cache trên RAM.
- Truy cập page nén có latency thấp hơn rất nhiều so với đọc từ swap trên đĩa.
- Kỹ thuật này làm bộ đệm trước khi phải sử dụng swap.

4) Host-level SSD Swapping:
- Nếu host có ổ SSD/Flash cục bộ (local flash device), VMkernel có thể swap page ra SSD thay vì HDD.
- SSD có latency thấp hơn HDD hàng chục lần, tránh được network latency khi swap qua mạng.
- Đây là bước trung gian trước khi phải dùng VM memory paging trên shared storage.

5) VM Memory Paging (.vswp file) – BIỆN PHÁP CUỐI CÙNG:
- VMkernel swap page của máy ảo ra file .vswp trên datastore.
- Đây là biện pháp với hiệu suất TỆ NHẤT: mỗi lần truy cập page bị swap, cần đọc từ đĩa qua mạng storage, tạo latency rất lớn.
- Nếu nhiều máy ảo cùng bị paging, hiệu suất toàn bộ host suy giảm nghiêm trọng.

VI.4. Swap Files​

vSphere sử dụng hai loại swap file cho mỗi máy ảo:

• .vswp (VM swap file): Lưu trữ page bộ nhớ máy ảo bị swap ra đĩa. Kích thước = (configured memory) – (reserved memory). Nếu máy ảo có reservation bằng với configured memory, file .vswp có kích thước 0.

• vmx-*.vswp (VMX process swap): Lưu trữ overhead bộ nhớ của tiến trình VMX (tiến trình điều khiển máy ảo trên host). Kích thước nhỏ, thường vài chục MB.

VI.5. Máy ảo đa lõi​

Khi cấu hình vCPU cho máy ảo, cần xem xét:

• Kiến trúc vật lý: Số socket, cores per socket, threads per core của host ảnh hưởng đến cách VMkernel lập lịch vCPU.

• Guest OS: Một số license OS giới hạn số socket (ví dụ: Windows Server Standard chỉ hỗ trợ 2 socket). Có thể cấu hình 4 vCPU dưới dạng 2 socket × 2 cores hoặc 1 socket × 4 cores tuỳ yêu cầu license.

• Nhu cầu ứng dụng: Ứng dụng đa luồng hưởng lợi từ nhiều vCPU. Ứng dụng đơn luồng không cần nhiều vCPU – thêm vCPU không tăng hiệu suất mà còn tăng overhead scheduling.

VMkernel CPU scheduler lập lịch động các vCPU, xem xét topology socket-core-thread của CPU vật lý để tối ưu hiệu suất (ví dụ: ưu tiên đặt vCPU trên cùng socket để tận dụng shared cache).

VI.6. Hyperthreading​

Hyperthreading (Intel HT) cho phép mỗi lõi vật lý thực thi 2 thread đồng thời. Mỗi thread xuất hiện như một logical processor riêng biệt.

Đặc điểm:
- Không tăng gấp đôi sức mạnh xử lý. Hai thread chia sẻ tài nguyên core (execution units, cache). Mức tăng hiệu suất thực tế khoảng 10-30% tuỳ workload.

- Logical processor có số CPU liền kề. Ví dụ: Core 0 → CPU 0 và CPU 1; Core 1 → CPU 2 và CPU 3.

- VMkernel sử dụng mỗi logical processor một cách độc lập để lập lịch vCPU.

- VMkernel ưu tiên phân bổ vCPU lên các core khác nhau trước khi sử dụng thread thứ hai trên cùng core, nhằm tối đa hoá hiệu suất thực tế.

VI.7. Cân bằng tải CPU​

VMkernel thực hiện cân bằng tải CPU liên tục:

- Kiểm tra mỗi 2 đến 40 mili giây (tuỳ tải hệ thống).

- Ưu tiên phân bổ vCPU lên các core khác nhau thay vì cùng-core threads. Chỉ sử dụng thread thứ hai trên cùng core khi tất cả core khác đã bận.

- Halted idle logical processor: Khi một logical processor ở trạng thái nhàn rỗi (idle) và không có vCPU nào cần lập lịch, VMkernel đưa nó vào trạng thái halt. Logical processor halt giải phóng tài nguyên core cho thread còn lại trên cùng core, giúp thread đang hoạt động chạy nhanh hơn.

VII: RESOURCE CONTROLS​

VII.1. Reservations (Đặt trước)​

Reservation đảm bảo mức tài nguyên tối thiểu cho máy ảo:

• CPU Reservation: Đơn vị MHz. Giá trị mặc định = 0 (không đặt trước). Ví dụ: reservation 2000 MHz đảm bảo máy ảo luôn có ít nhất 2000 MHz CPU khả dụng.

• Memory Reservation: Đơn vị MB. Giá trị mặc định = 0. Ví dụ: reservation 2048 MB đảm bảo máy ảo luôn có ít nhất 2 GB RAM vật lý.

Nguyên tắc hoạt động:
- Máy ảo sẽ không thể power on nếu host không có đủ tài nguyên chưa được đặt trước. vCenter kiểm tra admission control trước khi cho phép bật máy ảo.

- Bộ nhớ đã reserved không bao giờ bị swap hoặc balloon. VMkernel luôn giữ machine memory thực cho phần reserved, đảm bảo hiệu suất ổn định.

- Overhead memory: Ngoài bộ nhớ cho máy ảo, host cần thêm bộ nhớ overhead cho VMkernel để quản lý máy ảo (virtual hardware emulation, page tables, v.v.). Ví dụ: một máy ảo 4 GB RAM với 2 vCPU cần khoảng 53 MB overhead memory. Overhead này phải sẵn có trên host.

VII.2. Limits (Giới hạn)​

Limit đặt giới hạn trên cho tài nguyên máy ảo có thể tiêu thụ:

• Memory Limit: Khi máy ảo đạt memory limit, phần bộ nhớ vượt quá sẽ bị swap ra file .vswp, gây suy giảm hiệu suất.

• CPU Limit: Khi máy ảo đạt CPU limit, vCPU bị đặt vào trạng thái ready thay vì được lập lịch chạy, dẫn đến CPU ready time tăng cao.

KHUYẾN NGHỊ: Thường không nên đặt limit trừ khi có lý do rõ ràng và cụ thể. Lý do:
- Limit lãng phí tài nguyên nhàn rỗi (idle resources). Khi host có CPU/RAM dư, máy ảo bị limit không thể tận dụng tài nguyên dư đó, trong khi các máy ảo khác có thể không cần.
- Limit gây degradation giả tạo: máy ảo bị hạn chế ngay cả khi host không có tranh chấp tài nguyên.
- Chỉ đặt limit khi có lý do kinh doanh rõ ràng (ví dụ: khách hàng hosting trả tiền cho mức tài nguyên cụ thể).

VII.3. Shares (Chia sẻ theo tỷ lệ)​

Shares xác định mức ưu tiên tương đối giữa các máy ảo khi có tranh chấp tài nguyên . Khi không có tranh chấp, shares không có tác dụng – tất cả máy ảo nhận được tài nguyên cần thiết.

Tỷ lệ High : Normal : Low = 4 : 2 : 1

Giá trị CPU Shares mặc định (trên mỗi vCPU):
- High: 2000 shares per vCPU
- Normal: 1000 shares per vCPU
- Low: 500 shares per vCPU
Ví dụ: VM có 4 vCPU ở mức Normal = 4 × 1000 = 4000 CPU shares.

Giá trị Memory Shares mặc định (trên mỗi MB bộ nhớ cấu hình):
- High: 20 shares per MB
- Normal: 10 shares per MB
- Low: 5 shares per MB
Ví dụ: VM có 4096 MB RAM ở mức Normal = 4096 × 10 = 40,960 memory shares.

Ngoài các mức preset, quản trị viên có thể đặt giá trị Custom tuỳ ý.

Đặc điểm quan trọng:
- Shares là giá trị tương đối, không tuyệt đối. Khi thêm hoặc bớt máy ảo trong resource pool, tổng shares thay đổi, dẫn đến tỷ lệ phân bổ của mỗi máy ảo cũng thay đổi tương ứng.
Ví dụ: 2 VM cùng Normal → mỗi VM 50%. Thêm VM thứ 3 Normal → mỗi VM 33.3%.

- Shares chỉ có ý nghĩa khi tài nguyên bị tranh chấp. Trong điều kiện bình thường (host còn dư tài nguyên), tất cả máy ảo đều nhận đủ tài nguyên bất kể giá trị shares.