KVM, Xen hay LXC: VPS của bạn chạy gì?

VPS thực sự đang bán cho bạn điều gì

KVM, Xen và LXC là ba nhóm công nghệ ảo hóa làm nền tảng cho một gói VPS. Lựa chọn này không chỉ là chi tiết trong rack của nhà cung cấp. Nó quyết định bạn có kernel riêng hay không. Mọi điều người mua quan tâm đều bắt nguồn từ thực tế đó: nạp module, kiểm soát swap, chạy ảo hóa lồng nhau, liệu /proc mô tả server của bạn hay của người khác, và liệu có thể đo được steal time hay không.

Ảo hóa toàn phần (KVM và Xen HVM) cung cấp cho mỗi tenant một kernel và một máy ảo. Xen paravirtualization cũng cung cấp cho bạn một kernel, nhưng kernel này biết nó đang chạy với tư cách guest và yêu cầu hypervisor thực hiện các tác vụ đặc quyền. Gói container (LXC hoặc dòng OpenVZ và Virtuozzo) cung cấp cho bạn filesystem và một tập hợp namespace trên kernel của nhà cung cấp. Cả ba loại đều được bán dưới cùng ba chữ cái đó.

KVM so với Xen và LXC: mỗi máy một kernel hay dùng chung một kernel

Trên KVM và Xen, uname -r là kernel của bạn. Bạn có thể cài một kernel khác, load module vào kernel đó rồi reboot để dùng kernel mới. Những gì bạn làm ở đó không ảnh hưởng đến tenant khác. Với gói container, uname -r là kernel của nhà cung cấp đang chạy trên host và được dùng chung với mọi container khác trên máy đó. Bạn không thể thay đổi kernel này, còn apt install linux-image-generic sẽ chỉ giải nén các file mà hệ thống không bao giờ boot được.

Chỉ khác biệt này đã quan trọng hơn mọi bảng thông số. Hãy đọc phần còn lại của hướng dẫn này như các hệ quả của nó.

Ảo hóa đầy đủ: KVM và Xen HVM

KVM (kernel-based virtual machine) là một module trong Linux kernel, biến một máy chủ Linux thông thường thành hypervisor bằng các instruction Intel VT-x hoặc AMD-V tích hợp trong CPU. QEMU cung cấp phần cứng ảo xung quanh nó: disk, network card và serial console. Xen có thiết kế khác. Xen là một hypervisor riêng và khởi động trước Linux. Một control domain có quyền cao, gọi là dom0, chạy management stack. Mỗi tenant là một domU. Xen HVM (hardware virtual machine) sử dụng cùng các CPU extension như KVM, thường kèm paravirtual driver cho disk và network vì phần cứng mô phỏng chạy chậm. Tổ hợp này được gọi là PVHVM.

Đối với tenant, hai loại này gần như hoạt động giống hệt nhau. Bạn có kernel, bootloader, block device thực, một modprobe hoạt động, một /proc đúng nghĩa, swap do bạn quản lý và thao tác reboot thực sự khởi động lại máy. Nếu provider cho phép attach ISO, bạn có thể cài một distribution mà họ không cung cấp.

Đổi lại, mật độ máy ảo thấp hơn. 4 GB của bạn được dành riêng cho máy và không thể cho máy bên cạnh mượn khi bạn không dùng, đồng thời mỗi guest phải chạy một process QEMU, có page table riêng và page cache riêng. Chi phí này là lý do một gói KVM có giá cao hơn gói container dù hiển thị cùng các thông số.

Xen paravirtual hoá và cách nhận biết

Xen PV xuất hiện trước khi CPU có instruction hỗ trợ virtualisation. Thay vì bắt các privileged instruction, kernel của guest được sửa để gọi trực tiếp đến hypervisor. Nó chạy mà không cần VT-x, đúng với mục đích ban đầu vào năm 2005. Kernel được pygrub hoặc pvgrub nạp từ chính disk image của bạn. Đây là kernel của bạn, nhưng phải được build với hỗ trợ PV guest.

Dấu hiệu cho thấy bạn đang chạy trên Xen PV: lscpu báo loại virtualisation là para thay vì full, có /sys/hypervisor/type và file này cho biết Xen, còn disk của bạn là xvda thay vì vda hoặc sda. Các tool đọc bảng SMBIOS hoặc DMI sẽ không tìm thấy dữ liệu, vì PV guest không có firmware để cung cấp các bảng này.

Bạn sẽ mất nested virtualisation vĩnh viễn. PV guest không bao giờ được hiển thị các CPU virtualisation extension, nên không hypervisor nào có thể chạy bên trong nó. Xen không biến mất. Chỉ riêng Xen PV đang dần lỗi thời; hướng phát triển của dự án đã chuyển sang PVH và HVM. Nếu một plan chỉ ghi “Xen”, hãy hỏi đó là loại nào. HVM là VPS hiện đại thông thường. PV là loại plan mà bạn nên trả mức giá thấp hơn.

VPS container: LXC và dòng OpenVZ

VPS container là tập hợp các Linux namespace (chế độ xem riêng cho process ID, mount, network interface, hostname và user) cùng cgroups (control group, giới hạn tài nguyên do kernel áp dụng), chạy trên kernel của nhà cung cấp. init của bạn là một process trên host. ls của bạn chạy trực tiếp trên kernel của host, không có lớp mô phỏng và không có scheduler thứ hai cản trở. Vì vậy container có tốc độ cao và mật độ triển khai lớn.

Tên sản phẩm trên trang đặt hàng thường là LXC, Proxmox VE container (vốn là LXC), OpenVZ và Virtuozzo. OpenVZ 7 và Virtuozzo là các sản phẩm thương mại phát triển từ cùng một ý tưởng.

Có 4 điểm thay đổi đối với bạn:

• Module. modprobe sẽ không insert được gì. Nếu WireGuard, ZFS hoặc một netfilter module cụ thể chưa có trong kernel của nhà cung cấp, bạn không thể sử dụng nó.
• sysctl. Phần lớn /proc/sys chỉ ở chế độ read-only. Networking là một namespace thực sự, nên net.ipv4.ip_forward và các thành phần liên quan thường có thể ghi. Các thiết lập cấp toàn máy như vm.swappiness hoặc fs.file-max thuộc về host.
• Container lồng nhau. Docker bên trong một LXC container chỉ hoạt động khi nhà cung cấp bật nesting và storage driver tương thích. Hãy kiểm tra trước khi mua, đừng mặc định rằng tính năng này sẽ hoạt động.
• Phiên bản kernel. Bạn phụ thuộc vào lịch nâng cấp của nhà cung cấp, bao gồm cả các lần reboot.

Cách xác định loại máy bạn đã mua

Chạy các lệnh sau trên máy chủ và xem kết quả cùng nhau. Không có lệnh đơn lẻ nào đủ để kết luận.

systemd-detect-virt
systemd-detect-virt -c
lscpu | grep -iE 'hypervisor|virtualization'
uname -r
ls /lib/modules/$(uname -r) 2>/dev/null | head -n 3
cat /sys/hypervisor/type 2>/dev/null

systemd-detect-virt in ra một mã định danh ngắn từ một nhóm giá trị cố định. Nhóm kết quả phía máy chủ gồm kvm, qemu, xen, amazon và vmware. Nhóm kết quả phía container gồm lxc, lxc-libvirt, openvz, docker và systemd-nspawn. Khi không phát hiện được gì, lệnh in none và thoát với mã khác 0. Dạng -c chỉ kiểm tra các công nghệ container, nên bất kỳ kết quả nào khác none ở đây đều đủ để kết luận, bất kể trang bán hàng ghi gì.

lscpu cho biết vendor của hypervisor và xác định loại virtualisation là full hay para. Đây là cách phân biệt Xen HVM với Xen PV. /sys/hypervisor/type chỉ tồn tại trong môi trường Xen.

/lib/modules là bước kiểm tra mà nhiều người bỏ qua, nhưng cũng là bước trực tiếp nhất. Nếu thư mục tương ứng với phiên bản kernel đang chạy bị thiếu hoặc rỗng trong khi hệ thống rõ ràng đang chạy kernel đó, kernel không đến từ filesystem của bạn. Kernel được cung cấp bởi host, và cây module của nó chưa từng được cài vào image của bạn. Đây là container.

Để có thêm một kết quả kiểm tra độc lập, sudo apt install -y virt-what && sudo virt-what chạy các bài kiểm tra phát hiện dưới dạng một tool chuyên dụng. Lệnh này cần root và hoàn toàn không in gì trên bare metal.

Vì sao /proc mô tả sai máy trong container

Trên guest KVM hoặc Xen, /proc/meminfo là thông tin accounting của kernel riêng về lượng memory hypervisor cấp cho bạn. Thông tin này đúng với máy của bạn và không cho biết gì về host. Đó là mục đích của virtual machine.

Trong container không có kernel thứ hai thực hiện việc accounting đó, nên /proc là /proc của host. LXCFS là một filesystem nhỏ, viết lại một số file để phản ánh giới hạn cgroup của bạn. Nó bao phủ /proc/cpuinfo, /proc/meminfo, /proc/stat, /proc/uptime, /proc/swaps, /proc/diskstats và /sys/devices/system/cpu/online. Proxmox mount filesystem này theo mặc định. Nhiều provider nhỏ không làm vậy. Khi đó free -m báo tổng memory của host, nproc có thể báo toàn bộ số core của máy, còn uptime báo thời gian host đã chạy.

Đây không chỉ là vấn đề hiển thị, vì software tự điều chỉnh kích thước dựa trên các file này. nginx cùng với worker_processes auto đếm số core mà nó nhìn thấy. make -j$(nproc) trên host 64 core với quota 2 core sẽ khởi chạy 64 compiler. JVM hoặc database chọn kích thước cache từ MemTotal sẽ chọn một giá trị mà cgroup không cho phép. Kernel sẽ kill process khi process đạt đến giới hạn. Sự kiện kill đó được ghi vào kernel log của host, nơi bạn không thể đọc.

Các giá trị chính xác nằm trong cgroup, không nằm trong /proc:

cat /sys/fs/cgroup/memory.max
cat /sys/fs/cgroup/memory.current
cat /sys/fs/cgroup/cpu.max

Đó là các path của cgroup v2, loại cgroup mà các distribution hiện tại sử dụng. memory.max đọc max có nghĩa là cấp đó không đặt giới hạn. cpu.max in quota và period theo microsecond, nên 200000 100000 tương ứng với 2 core CPU time trong mỗi period. Trên host cgroup v1 cũ hơn, các giá trị tương tự nằm dưới /sys/fs/cgroup/memory/memory.limit_in_bytes và /sys/fs/cgroup/cpu/cpu.cfs_quota_us.

Swap và bên thực sự sở hữu nó

Trên KVM và Xen, swap thuộc về bạn. Đó là một file hoặc partition trên disk của bạn, và kernel của bạn thực hiện paging.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

swapon --show hiện phải liệt kê file cùng size và priority của file đó. Nếu swapon từ chối file, hãy tạo file bằng dd if=/dev/zero of=/swapfile bs=1M count=2048 thay thế, vì một file được cấp phát trước nhưng có extent chưa được ghi sẽ bị một số filesystem từ chối. Thêm /swapfile none swap sw 0 0 vào /etc/fstab, nếu không swap sẽ biến mất sau lần reboot tiếp theo.

Trong container, không có phần nào trong số đó thuộc về bạn. swapon cần một capability mà container không đặc quyền không có, nên việc tạo swap file riêng sẽ fail do permission và không bao giờ ghi được xuống disk. Thứ mà plan gọi là swap thực ra là một thiết lập cgroup trên host, memory.swap.max trong cgroup v2, được cung cấp bởi các swap device của chính host. Các plan OpenVZ cũ bán một mức cho phép “vswap”, hoạt động giống burst credit hơn là disk. Bạn có thể đọc giới hạn. Bạn không kiểm soát device nằm phía dưới giới hạn đó.

Ảo hóa lồng nhau và CPU flag gây hiểu lầm

Ảo hóa lồng nhau là chạy một hypervisor bên trong VPS của bạn: một guest QEMU, một box Vagrant hoặc một lab ảo hóa lồng nhau có các VM riêng. Cả 2 điều kiện đều phải được đáp ứng. Nhà cung cấp phải bật tính năng nesting trên host, và guest của bạn phải được cung cấp các extension ảo hóa của CPU.

lscpu | grep -i virtualization
ls -l /dev/kvm
sudo apt install -y cpu-checker && sudo kvm-ok

Trên KVM guest đã bật nesting, /dev/kvm tồn tại và kvm-ok cho biết rõ acceleration có thể được sử dụng hay không. Trên Xen HVM, về mặt kỹ thuật có thể thực hiện nhưng hiếm khi được cung cấp. Trên Xen PV, việc này không thể thực hiện.

Trong container, phép kiểm tra này thất bại theo một cách cho thấy rõ vấn đề. /proc/cpuinfo là file của host, nên flag vmx hoặc svm xuất hiện và hoàn toàn đúng: CPU vật lý bên dưới bạn thực sự có các instruction đó. Nhưng các instruction này vẫn không thuộc quyền sử dụng của bạn. Không có /dev/kvm trong namespace của bạn, bạn không thể load module kvm_intel, và flag vừa đọc mô tả máy mà bạn đang làm guest trên đó, thay vì một máy do bạn kiểm soát. Đây là trường hợp rõ nhất của quy tắc tổng quát. Trong container, /proc mô tả namespace và phần cứng xung quanh nó, không phải một server thuộc quyền sở hữu của bạn.

AES-NI và các tính năng CPU mà plan của bạn cung cấp

AES-NI (advanced encryption standard new instructions) là một tập lệnh CPU giúp mã hóa AES nhanh hơn nhiều lần so với thực hiện cùng phép tính bằng software. TLS termination, mã hóa disk, SSH và các pipeline backup đều phụ thuộc nhiều vào nó.

Trên KVM, guest nhìn thấy CPU nào phụ thuộc vào CPU model mà provider cấu hình cho QEMU. Với host passthrough, bạn nhìn thấy các flag thực tế. Với model chung như qemu64, hoặc baseline cũ được chọn có chủ ý để guest có thể migrate giữa các host không đồng nhất, flag aes có thể không xuất hiện. Khi đó, OpenSSL âm thầm chuyển sang software path.

lscpu | grep -ow aes | head -n 1
openssl speed -evp aes-128-gcm
env OPENSSL_ia32cap='~0x200000000000000:~0x20000000000:~0x0:~0x0:~0x0' openssl speed -evp aes-128-gcm

Command thứ ba là ví dụ trong manual của OpenSSL để tắt các instruction đó bên trong library. Nó xóa bit AES-NI và bit VAES, đồng thời giữ nguyên các bit còn lại. Hãy so sánh 2 con số throughput. Nếu chúng gần bằng nhau, fast path vốn chưa được sử dụng. Khi đó, kiểm tra AES-NI trên VPS đúng cách là việc đáng dành 5 phút trước khi bạn chốt một plan.

Container không có CPU model riêng, vì vậy các flag trong /proc/cpuinfo là flag thực tế của host và áp dụng cho bạn. Đây là một lợi thế thực sự của các plan container. Đây cũng là nơi duy nhất trong hướng dẫn này mà kernel dùng chung có lợi cho bạn.

Steal time đến từ đâu và vì sao container không có

Steal time là khoảng thời gian vCPU ảo của bạn đã sẵn sàng chạy nhưng không được chạy, vì hypervisor đang chạy workload khác. Chỉ số này xuất hiện dưới dạng st trong top và vmstat, và là trường thứ tám của dòng cpu trong /proc/stat.

Guest không thể tự đo chỉ số này, vì guest không thực thi trong lúc thời gian đó bị lấy đi. Hypervisor phải cung cấp thông tin này. KVM ghi tổng thời gian đang chạy vào một page mà guest đăng ký thông qua giao diện paravirtual clock, còn Xen duy trì một vùng trạng thái chạy riêng cho từng vCPU để làm việc tương tự. Con số bạn đọc được là thông tin do chính hypervisor cung cấp. Vì vậy nó tồn tại và đáng tin cậy.

Steal cao nghĩa là host đang oversubscribed và các tenant bên cạnh đang bận tại thời điểm đó. Đây là biểu hiện trực tiếp của tỷ lệ giữa số vCPU đã bán và số core vật lý. Đọc steal time để phát hiện noisy neighbour là phép đo duy nhất cho biết plan có thực sự lớn như thông tin công bố hay không.

vmstat 1 5
cat /sys/fs/cgroup/cpu.stat

Trong container, cột đó sẽ không thay đổi vì không có hypervisor nằm giữa bạn và scheduler. Process của bạn xếp hàng cùng process của mọi tenant khác dưới dạng task thông thường trong CPU scheduler của host. Tình trạng tranh chấp chỉ thể hiện qua việc workload mất nhiều thời gian hơn, không có counter nào nêu rõ nguyên nhân. Chỉ số tương đương gần nhất là quota throttling: khi provider đặt cpu.max, /sys/fs/cgroup/cpu.stat sẽ đếm số chu kỳ nr_throttled và số microsecond throttled_usec đã chờ đến quota window tiếp theo. Chỉ số này chỉ bao quát quota của bạn, không bao giờ phản ánh sự cạnh tranh từ các tenant bên cạnh. Lưu ý: nếu container host của provider bản thân là một virtual machine, steal figure có thể xuất hiện trong /proc/stat, nhưng đó là chỉ số của host này chứ không phải của bạn.

Bán quá mức và vì sao gói container rẻ hơn

Câu trả lời thực tế rất ngắn gọn. Gói container có giá thấp hơn vì nhà cung cấp chia sẻ nhiều hơn cùng một máy cho nhiều người hơn.

Bộ nhớ là nơi chênh lệch lớn nhất. RAM của một KVM guest được dành riêng cho guest đó, nên một host có 256 GB sẽ bán khoảng 256 GB cho các guest, trừ phần overhead. Giới hạn bộ nhớ của container là mức trần thay vì phần được dành riêng. Phần bộ nhớ container không sử dụng sẽ lập tức khả dụng cho các container khác. Vì vậy, nhà cung cấp có thể bán tổng giới hạn cao gấp vài lần RAM vật lý mà hầu như lúc nào cũng đáp ứng được. Không có gì bị giả mạo. Mô hình này hoạt động cho đến khi có đủ nhiều tenant bận cùng lúc. Khi đó, nó ngừng hoạt động đối với tất cả mọi người.

CPU bị oversell trên mọi loại gói, kể cả KVM, bằng cách bán nhiều vCPU hơn số core thực tế. Disk gần như luôn được thin provision. Container còn tăng thêm mật độ trên nền đó: một kernel, một page cache và không có tiến trình QEMU riêng cho từng guest, nên một host có thể chứa nhiều tenant hơn vài lần.

Điều bạn đánh đổi là khả năng cô lập. Đây là một đánh đổi kỹ thuật thực tế, không phải câu chuyện nhằm gây sợ hãi. Bạn dùng chung một kernel, nên lỗi kernel là vấn đề chung. Nếu container escape xảy ra, kẻ tấn công sẽ truy cập trực tiếp vào host. Để thoát khỏi một virtual machine cần khai thác lỗi trong hypervisor, đây là mục tiêu nhỏ hơn nhiều và khó tấn công hơn đáng kể. Bạn cũng phải phụ thuộc vào lịch nâng cấp kernel và reboot của nhà cung cấp. Nếu những điểm này quan trọng với bạn, hãy đọc VPS hosting thực sự an toàn đến mức nào trước khi chỉ chọn dựa trên giá.

Nên mua loại nào

Chọn KVM khi bạn cần kernel riêng: module WireGuard hoặc ZFS, một phiên bản kernel cụ thể, nested virtualisation, quyền kiểm soát thực sự đối với swap, hoặc một ranh giới cô lập có thể giải thích với auditor. Chọn gói container khi bạn chạy các service thông thường với ngân sách hạn chế, kernel của nhà cung cấp đang được cập nhật, và bạn đã xác nhận các tính năng mình phụ thuộc vào đã được compile sẵn trong kernel đó. Với hầu hết mục đích sử dụng, hãy xem Xen HVM tương đương với KVM. Trước khi mua, hãy hỏi kỹ nếu sản phẩm vẫn được bán dưới dạng Xen PV.

Có 2 mô hình nằm ngoài phân loại này. Firecracker microVM cung cấp kernel thực cho từng tenant, với thời gian khởi động gần bằng container. Đây là mô hình các nền tảng serverless sử dụng. Incus system container cho phép bạn tự chạy mô hình container trên phần cứng mình kiểm soát. Đây là vị thế khác với việc mua một container do nhà cung cấp bán sẵn. Nếu vướng mắc nằm ở thuật ngữ, VPS thực sự là gì và sự khác nhau giữa VPS, VM và VPC giải thích các khái niệm mà hướng dẫn này giả định bạn đã biết.

FAQ

Làm thế nào để biết VPS của tôi là KVM hay container?

Chạy systemd-detect-virt -c. Bất kỳ kết quả nào khác none đều có nghĩa là bạn đang ở trong một container, bất kể plan mang tên sản phẩm nào. Hãy xác nhận thêm bằng 2 cách, vì cơ chế phát hiện có thể bị đánh lừa. lscpu cho biết nhà cung cấp hypervisor và nêu loại virtualisation là full hay para. ls /lib/modules/$(uname -r) sẽ không tồn tại hoặc rỗng trong container, vì kernel đang chạy được lấy từ host và cây module của nó chưa bao giờ được cài trong filesystem của bạn. sudo virt-what đưa ra kết quả độc lập từ một tool được viết riêng cho câu hỏi này.

Vì sao free -m hiển thị nhiều memory hơn mức plan của tôi?

Bạn đang dùng container plan nhưng chưa mount LXCFS, nên /proc/meminfo là file của host và free đang báo chính xác lượng memory của host. Giới hạn thực tế của bạn là cgroup. Đọc /sys/fs/cgroup/memory.max để xem giới hạn và /sys/fs/cgroup/memory.current để xem mức sử dụng hiện tại, hoặc dùng /sys/fs/cgroup/memory/memory.limit_in_bytes trên host cgroup v1 cũ hơn. Hãy cấu hình mọi service lấy số liệu này để tính kích thước cache hoặc worker pool, thay vì lấy từ free.

Tôi có thể chạy Docker hoặc WireGuard trên LXC VPS không?

Đôi khi có thể, và không phải nhờ bất kỳ thứ gì bạn cài đặt. Cả hai đều phụ thuộc vào kernel của provider, vì bạn không thể load module vào đó. WireGuard hoạt động khi module đã có sẵn trên host và được expose cho bạn; nếu không, implementation userspace wireguard-go là phương án dự phòng. Docker cần provider cho phép nesting và cần storage driver hoạt động được bên trong container. Hãy hỏi trước khi mua, hoặc test trên một term mà bạn có thể bỏ bất cứ lúc nào.

Vì sao container VPS của tôi không bao giờ báo steal time?

Steal time chỉ tồn tại khi hypervisor đang lập lịch cho một virtual CPU. Nó được báo cáo vì hypervisor ghi giá trị này vào một page mà kernel của bạn đọc được. Container không có hypervisor bên dưới. Các process của bạn là những task thông thường trong scheduler của host, nên tình trạng tranh chấp chỉ thể hiện bằng việc mọi thứ chạy lâu hơn, không có counter nào để chỉ ra nguyên nhân. Thay vào đó, hãy đọc /sys/fs/cgroup/cpu.stat: nr_throttled và throttled_usec đếm thời gian cgroup của bạn phải chờ cửa sổ quota CPU tiếp theo. Đây là chỉ số gần nhất với steal time mà container có.