HỆ THỐNG ĐIỆN TOÁN ĐÁM MÂY TƯ NHÂN GREAT LOTUS · NIRVANA FRAMEWORK

Mổ xẻ từng thành phần giao diện · Kiến trúc ảo hoá Proxmox VE · Công nghệ cắt lát vGPU
Quy trình an toàn, sao lưu, phục hồi thảm hoạ và giáo án thực hành

Lotus Cloud — nền tảng đám mây tư nhân đặt trên hạ tầng ảo hoá Proxmox VE.

Hạng mục	Nội dung
Đối tượng	Kỹ sư vận hành hạ tầng, quản trị hệ thống, lập trình viên dùng máy ảo, và học viên các lớp đào tạo nội bộ Great Lotus
Phiên bản tài liệu	Bản 3 — biên soạn lại toàn bộ ngày 07/09/2026, cập nhật 11/09, 12/09, 13/09 và 19/09/2026; đối chiếu trực tiếp với mã nguồn và hệ thống đang chạy
Đối tượng mô tả	Container lotus_cloud · IP nội bộ 114.114.114.43 · cổng máy chủ 20430 · mở tại http://172.16.10.220:20430/
Hạ tầng kiểm chứng	Workpool 1 (HP1 172.16.10.220) · pve-wp2-01 (WP2) · và node pve-wp2-02 — nay đã đổi tên thành pve-001, ngày 13/09/2026 nằm ở WP3 172.16.30.102. Từ 19/09 B43 chỉ còn khai một máy chủ này
Nguồn sự thật	Mã nguồn B43_Lotus_Cloud/app/, tài liệu kỹ thuật nội bộ docs/huong-dan-su-dung-va-kiem-thu.md, và ảnh chụp trực tiếp hệ thống thật* qua trình duyệt điều khiển B35

GHI CHÚ · CÁCH ĐỌC GIÁO TRÌNH NÀY

Mỗi màn hình được chụp từ hệ thống ĐANG CHẠY, đánh số bằng vòng tròn chỉ tô viền đặt bên ngoài phần tử — không có mảng màu đè lên giao diện, nên bạn vẫn đọc được nguyên vẹn chi tiết bên dưới. Sau mỗi hình là một bảng giải thích đủ mọi thành phần nhìn thấy trên màn hình đó, kể cả những thứ chỉ hiện trong một trạng thái nhất định.

▸ Phần chữ in đậm là điều dễ làm sai nhất — đọc kỹ trước khi thao tác.

▸ Hộp màu ĐỎ là thao tác phá huỷ dữ liệu: đọc hết hộp rồi mới bấm.

▸ Hộp màu XANH LÁ mô tả hành vi trông như lỗi nhưng đúng thiết kế — đừng đi báo lỗi.

Lời nói đầu — vì sao có bản viết lại này

Bản đầu tiên của giáo trình được sinh tự động và mô tả hệ thống ở mức khái quát. Khi đem đối chiếu với mã nguồn B43_Lotus_Cloud/app/ và với chính màn hình đang chạy, có khá nhiều chỗ lệch: bảng danh sách máy ảo được mô tả 8 cột trong khi thực tế có 12 cột; trang chi tiết máy được mô tả 4 ô số liệu trong khi thực tế có 6 ô cộng một khối biểu đồ 24 giờ; nhiều mã phần tử HTML được nêu ra không tồn tại trong mã nguồn; và một số con số ấn tượng — “khôi phục trong 3 giây”, “tạo máy trong 40 giây” — không có nguồn nào chứng minh.

Với một cuốn sách dùng để giảng dạy, sai một con số là truyền sai cho cả lớp. Vì vậy bản này được dựng lại theo một nguyên tắc duy nhất:

ĐÚNG THIẾT KẾ · NGUYÊN TẮC BIÊN SOẠN

Mọi con số, mọi tên phần tử, mọi hành vi mô tả trong tài liệu này đều phải truy ngược được về một trong ba nguồn: (1) mã nguồn đang chạy trong container lotus_cloud; (2) tài liệu kỹ thuật nội bộ đã ghi kèm số đo thật; hoặc (3) ảnh chụp màn hình hệ thống lúc biên soạn. Chỗ nào chưa kiểm chứng được thì nói rõ là chưa kiểm chứng, chứ không lấp bằng một con số nghe hợp lý.

Điểm khác biệt lớn thứ hai là độ sâu. Yêu cầu đặt ra là không bỏ sót bất kỳ thành phần nào xuất hiện trên giao diện. Bản này vì thế mô tả cả những thứ trước đây không được nhắc tới một chữ: khối biểu đồ 24 giờ, hai chip địa chỉ IP LAN và Public trên thanh tiêu đề, thẻ Địa chỉ MAC, thẻ Định danh phần cứng, ổ đĩa cài đặt dùng chung, bảng “Cấu hình đang áp dụng” của card đồ hoạ, ô chọn kiểu vGPU, cây phả hệ bản mẫu với ba kiểu nét đường, bộ ngắt mạch cho node đang tắt, và khối tự làm mới 5 giây một lần của trang chi tiết.

Trạng thái hệ thống lúc biên soạn

Mọi ảnh chụp trong sách đều lấy từ hệ thống thật trong cùng một phiên làm việc. Ghi lại trạng thái đó để người đọc sau này biết mình đang nhìn cái gì:

Thành phần	Trạng thái lúc chụp ảnh (07/09/2026)
pve-wp2-01	Đang tắt (offline) — không với tới cổng 8006. Đây là lý do bạn thấy thẻ node màu xám kèm nút Send Wake-on-LAN trong nhiều hình; nó minh hoạ đúng hành vi đã thiết kế.
pve-wp2-02	Đang chạy. Proxmox VE 9.2.2, nhân 6.14.11-9-pve, khởi động EFI. CPU 2 × Intel Xeon E5-2673 v3 @ 2.40 GHz = 24 nhân / 48 luồng. RAM 94 GB (đang dùng ~19 GB).
Kho lưu trữ	local (dir, NVMe, 23/66 GB) · local-lvm (lvmthin, NVMe, 0/137 GB) · vmstore (lvmthin, SSD SATA, 74/466 GB)
Card đồ hoạ	NVIDIA GeForce GTX 1660 Ti 6 GB, chạy vgpu_unlock nên driver nhìn nó như Quadro RTX 6000. Đang chốt cách chia 6 × 1 GB, 3 chỗ đã dùng.
Máy ảo	#100 may-goc-gpu-gpm (tắt) · #102 template01-win10-gpu (bản mẫu) · #103 vpn-pc-01 (đang chạy, driver vGPU 553.74, đã cấp phép)
Dự án	CMEV-SERVER (xanh dương) và GREAT_LOTUS (hồng)

Bản cập nhật ngày 11/09/2026 — ổ đĩa, kho sao lưu, ổ chung

Máy chủ có thêm hai ổ cơ, một máy chủ sao lưu (Proxmox Backup Server), lịch sao lưu tự động và một ổ chung cho các máy ảo. Bản cập nhật này giữ nguyên mọi đoạn vẫn đúng của bản 07/09/2026, kể cả ảnh chụp; chỉ sửa những câu mà hệ thống thật đã làm cho sai, và thêm Phụ lục G. Danh sách đầy đủ những gì đã đổi:

Chỗ	Bản 07/09 ghi	Nay đúng là	Nguồn
Mục 1.3 — lịch sao lưu	Chưa làm	Đã giao cho Proxmox + PBS: 23:30 mỗi đêm. B43 vẫn không có bộ hẹn giờ riêng	/etc/pve/jobs.cfg
Mục 4.2 — bảng kho	Ba kho	Thêm kho pbs (HDD, Health 95%) · mục Ổ chung* ngay dưới bảng · vạch đỏ 80 % — G.3	Ảnh chụp trưa 11/09, node_shell.py, app.js
Mục 4.4 — tầng lưu trữ	Tầng HDD đã bị gỡ bỏ	Tầng HDD có lại: ổ 4 TB SMR và 500 GB CMR, làm kho sao lưu và ổ chung	lsblk, smartctl
Mục 4.4 — nơi đặt bản sao lưu	local hoặc NFS trên White NAS	pbs cho sao lưu hằng ngày; NAS vẫn là đích đúng khi tính tới mất node	pvesm status
Mục 12.1 — ô Lưu vào kho	Không nhắc	Có thêm pbs, đứng đầu danh sách	Ảnh chụp 11/09
Mục 12.1 — bản sao lưu container	Không nhắc	Ghi đúng tên, khôi phục được; hộp thoại cảnh báo bind mount, IP tĩnh — G.6	Khôi phục thử CT 299 qua B43
Phụ lục G.7 — cỡ khối ổ 4 TB	(bản sáng 11/09) pbs 500 · share 2976 · 250 GiB chưa cấp	pbs 646 · share 3080 · chưa cấp 0	lvs, vgs
Mục 16.2 — ma trận dữ liệu	Sao lưu thủ công	Tự động mỗi đêm vào PBS; ổ chung có ảnh chụp hardlink. Thêm mục 16.4	jobs.cfg, timer lotus-snap@
Mục 17.3 — mất node	Đúng	Giữ nguyên; thêm câu nhắc kho pbs nằm trên chính node	—
Phụ lục A · E · F	—	A giữ nguyên, thêm lời dẫn sang G · E thêm 11 thuật ngữ · F thêm nguồn của G	—

LƯU Ý · TÊN NODE ĐÃ ĐỔI — ẢNH CHỤP CŨ VẪN GHI TÊN CŨ

pve-wp2-02 trong các chương và ảnh chụp ngày 07/09/2026 chính là pve-001 hôm nay: cùng một máy, đã đổi tên, nhận địa chỉ DHCP và có thể dời giữa ba site. Ngày 11/09/2026 máy nằm ở WP3, địa chỉ 172.16.30.102. Bản cập nhật không chụp lại toàn bộ ảnh chỉ vì đổi tên, và thông số CPU, RAM ở Chương 4 chưa được đối chiếu lại.

Bản cập nhật ngày 12/09 và 13/09/2026 — ổ chung bằng ô tích, đổi tên hai nút nguồn

Ngày	Chỗ	Đã đổi thành	Nguồn
12/09	Mục 10.3 — tab Cài đặt	Thêm Khối 5 — Ổ chung (mạng): hai ô tích cho hai kho SMB F: (ổ nhanh) và S: (ổ chung), dùng chung một card mạng vào cầu nội bộ. Khối Vùng nguy hiểm lùi thành Khối 6	main.py O_CHUNG_KHO; ảnh chụp 12/09
12/09	Phụ lục G.4	Cầu vmbr1 đã có DHCP riêng (dải 10.77.0.100–199, không phát gateway và DNS) — bản trước khẳng định sai rằng cầu này không có DHCP	dnsmasq-vmbr1.conf
13/09	Mục 9.1 · Chương 10 · Phụ lục B.4	Hai nút nguồn đổi tên: Tắt mềm thành Tắt máy (ACPI), Tắt cứng thành Cắt điện. Chỉ đổi chữ hiển thị, hành vi giữ nguyên	app.js dòng 1827 và 1829

GHI CHÚ · ĐỢT 13/09 CHỈ CHỤP LẠI NĂM HÌNH

Đổi tên nút chỉ làm sai những hình có hàng nút nguồn ở đầu trang chi tiết: Hình 9.1 · 10.1 · 10.3 · 10.4 · 10.5. Đúng năm hình đó được chụp lại trên máy #103 đang chạy; 76 hình còn lại giữ nguyên vì không có gì đổi.

▸ Vì chụp lại hôm nay nên năm hình đó hiện tên node mới pve-001 và địa chỉ dải WP3 — khác các hình cũ, nhưng đó là hiện trạng đúng, không phải lỗi.

▸ Cách tìm ra đúng năm hình: cắt vùng hàng nút từ cả 81 ảnh rồi soi, không dựa vào trí nhớ.

Bản cập nhật ngày 19/09/2026 — bảo mật, cảnh báo, lịch sao lưu, Tạm dừng, USB

Từ 13/09 đến 18/09/2026, B43 nhận 28 lần thay đổi mã (git log của kho B43_Lotus_Cloud). Có ba trang mới hẳn, ba trang đổi mặt đáng kể, và vài chỗ sách cũ ghi sai ngay từ trước. Bản này vẫn giữ nguyên tắc cũ: đoạn nào còn đúng thì không đụng; chỉ sửa câu hệ thống đã làm cho sai, và thêm mục cho phần mới.

Chỗ	Bản 13/09 ghi	Nay đúng là	Nguồn
Mục 1.3 — ranh giới	Lịch sao lưu giao cho Proxmox; tường lửa, ổ phụ chưa làm; đồ thị node chưa làm	Lịch sao lưu quản lý ngay trên B43; đồ thị node đã có; tường lửa, ổ phụ, NIC/VLAN, token quyền hẹp: chủ động không làm (DŨNG chốt 18/09)	backups.py, quyết định 18/09
Mục 1.4 — bản đồ trang	9 trang	12 trang: thêm Cảnh báo, Hoạt động, Bảo mật	app.js hàm route()
Mục 2.5 — biến môi trường	Chưa có biến nào cho cảnh báo	Thêm 8 biến: 6 cho cảnh báo (Telegram, Slack, webhook, hai ngưỡng), 2 cho việc xoá bản sao lưu	docker-compose.yml, main.py
Mục 2.6, 2.7	—	Nhịp chung lấy mẫu và bộ test tự động — mục mới	§16.25, §16.34 tài liệu nội bộ
Mục 4.1 — thông số node	pve-wp2-02: 48 luồng, 94 GB (chưa đối chiếu lại)	pve-001: 2 × Xeon E5-2696 v4, 88 luồng, RAM 125 GiB; B43 nay chỉ khai một máy chủ	lscpu, free -g trên node
Mục 6.1, 6.2	Đăng nhập 1 lớp; thanh bên 10 mục	Ô mã xác thực khi 2FA bật; thanh bên thêm Cảnh báo (có số đỏ) và Hoạt động; tên người dùng thành liên kết sang Bảo mật	Ảnh chụp 19/09
Mục 7.1, 7.2, 7.5 — bảng Droplets	12 cột; nút Tắt luôn hỏi xác nhận	13 cột (thêm USB); nút Tắt ▾ mở menu bốn kiểu tắt, chỉ Cắt điện hỏi lại; nhãn Đang tạm dừng	app.js TAT_KIEU
Mục 9.1 — trang chi tiết	Bốn nút nguồn	Năm nút: thêm Tạm dừng	Ảnh chụp 19/09
Mục 10.3 — tab Cài đặt	Sáu khối	Tám khối: thêm USB Passthrough và Tạm dừng (ngủ); Vùng nguy hiểm lùi thành Khối 8	Ảnh chụp 19/09
Chương 11 — Hạ tầng	Bốn ô số liệu; ô Droplets đếm cả container	Năm ô (thêm Nhiệt CPU); ô CPU có số luồng đang chạy; sáu đồ thị theo thời gian; ô Droplets chỉ đếm máy QEMU (kể cả bản mẫu), không đếm container — sách cũ ghi sai	main.py list_vms gọi /qemu
Mục 12.1 — Sao lưu	Một bảng phẳng	Thẻ Lịch sao lưu tự động; bảng chia ba nhóm lưu trữ; cột Hạn còn lại; xem riêng một máy; nút Xoá báo đúng khi tác vụ hỏng	Ảnh chụp 19/09, commit 9ca4440
Chương 14	Chỉ card đồ hoạ	Thêm tab Cổng USB — gán từng cổng vật lý cho máy ảo	§16.28 tài liệu nội bộ
Mục 15.2 — đường không cần cookie	Đúng ba đường	Năm đường cộng một tiền tố — sách cũ ghi thiếu từ trước 13/09	main.py _MO_CHINH_XAC, test test_cau_truc.py
Mục 15.3 – 15.5	—	Ba lớp bảo vệ mới: 2FA, sổ Hoạt động, cảnh báo chủ động	Ảnh chụp + lịch sử cảnh báo thật
Chương 18 · 20 · Phụ lục D, E, F	—	Thêm 12 hiện tượng “trông như lỗi”; Bài 8; bảng API dựng lại đủ 119 endpoint / 99 đường dẫn; thêm thuật ngữ và nguồn	đếm tự động từ main.py
Phụ lục H, I	—	H — bẫy đã trả giá đợt 15–18/09; I — đối chiếu DigitalOcean và vSphere	memory + danh-gia-so-voi-do-vmware.md

GHI CHÚ · ĐỢT 19/09 CHỤP 18 HÌNH MỚI, VẼ LẠI 3 SƠ ĐỒ, THÊM 3 SƠ ĐỒ

Ảnh chụp chỉ cho những màn hình đã đổi. Mọi lệnh ghi (POST/PUT/DELETE) bị chặn ngay trong trình duyệt lúc chụp, nên mở menu Tắt, hộp Thêm lịch, bảng nhiệt… không đụng tới máy thật. Hai hình về cảnh báo đang mở là ảnh chụp thật ngày 18/09 lúc kiểm thử có chủ ý (hạ ngưỡng kho xuống 30 %), không phải ảnh dàn dựng.

▸ Xác thực hai lớp đang bật trên hệ thống thật — kịch bản chụp tự tính mã từ /data/totp.json của container (chỉ chạy được trên chính HP1).

▸ Các hình cũ vẫn hiện pve-wp2-02 và dải 172.16.20.x: đó là hiện trạng ngày chụp, không phải lỗi. Hình mới hiện WP3_PVE1 (nhãn hiển thị) của máy pve-001.

Mục lục

Mục lục dưới đây do Microsoft Word sinh ra từ chính các đề mục của tài liệu, nên luôn khớp số trang thật. Nếu mở bằng Word mà chưa thấy nội dung, bấm Ctrl+A rồi F9 (hoặc chuột phải → Update Field → Update entire table).

Chương 1 — B43 Lotus Cloud là gì, và không là gì

1.1 Định vị: một tầng trừu tượng, không phải một hypervisor

B43 Lotus Cloud là một bảng điều khiển web độc lập viết bằng FastAPI (Python) ở phía máy chủ và JavaScript thuần ở phía trình duyệt. Nó không ảo hoá gì cả. Toàn bộ việc tạo máy, cấp phát ổ đĩa, gán card đồ hoạ vẫn do Proxmox VE làm; B43 chỉ đứng phía trước, nhận yêu cầu bằng ngôn ngữ của người dùng rồi dịch sang ngôn ngữ của Proxmox.

Cách hiểu đúng nhất: Proxmox VE là động cơ, B43 là bảng táp-lô. Bỏ B43 đi thì các máy ảo vẫn chạy nguyên vẹn — chỉ là bạn phải quay lại nhìn thẳng vào những con số thô của động cơ.

Hình 1.1. Kiến trúc tổng thể. Chú ý ba đường ở khối dưới: chúng KHÔNG đi qua REST API của Proxmox, và chính chúng làm nên phần lớn giá trị của B43.

Vì sao lại cần một tầng như vậy

Giao diện gốc của Proxmox VE được thiết kế cho kỹ sư hạ tầng: nó phơi bày mọi tham số cấp thấp và không giấu gì cả. Điều đó tuyệt vời khi bạn biết mình đang làm gì, và rất nguy hiểm khi bạn không biết. Hai hình dưới đây đặt cạnh nhau cùng một hạ tầng, nhìn từ hai giao diện.

Hình 1.2. Giao diện Proxmox VE gốc trên node pve-wp2-02: cây thư mục nhiều tầng, bảng thuật ngữ cấp thấp (zone, pool, qemu, storage), cột Disk usage của máy ảo hiển thị 0.0 % — một con số đúng về mặt kỹ thuật nhưng vô nghĩa với người dùng.

Hình 1.3. Cùng hạ tầng đó nhìn từ B43: một bảng duy nhất, gộp máy của mọi node, có sẵn địa chỉ IP thật, dung lượng thật, loại ổ đĩa và trạng thái driver card đồ hoạ.

Tiêu chí	Proxmox VE gốc	B43 Lotus Cloud
Cách gom máy ảo	Cây thư mục theo từng node. Muốn xem toàn cảnh phải bấm qua lại.	Một bảng duy nhất gộp mọi node, mặc định xếp theo dự án.
Địa chỉ IP	Không có cột IP trong bảng tổng. Phải mở từng máy, tab Network.	Cột Địa chỉ IP lấy qua QEMU Guest Agent, hiện thẳng trên bảng.
Dung lượng ổ đĩa đã dùng	disk luôn trả 0 với máy ảo QEMU đang chạy ⇒ hiển thị 0 %.	Hỏi agent/get-fsinfo bên trong máy khách; không có agent thì hiện “—” kèm lý do.
Card đồ hoạ	Biết hostpci0 đã gắn. Không biết bên trong máy dùng được chưa.	Chip màu 5 trạng thái, đọc từ nvidia-smi chạy bên trong máy khách.
Ảnh màn hình máy ảo	Không có. Giao diện web của Proxmox cũng không có ảnh xem trước.	Có — đi đường SSH qm monitor → screendump.
Console	noVNC của Proxmox, phải đăng nhập Proxmox và vượt cảnh báo chứng chỉ tự ký.	B43 tự chuyển tiếp noVNC: không đăng nhập lại, không cảnh báo chứng chỉ.
Cách chia card đồ hoạ	Sửa tay /etc/vgpu_unlock/profile_override.toml qua SSH.	Trang Cấu hình máy chủ: chọn cách chia, xem trước, áp dụng.

1.2 Ba câu hỏi mà hypervisor KHÔNG tự trả lời được

Đây là phần học thuật quan trọng nhất của cả giáo trình. Hiểu được ba câu này thì hiểu vì sao B43 tồn tại; không hiểu thì mọi thứ còn lại chỉ là “một cái giao diện đẹp hơn”.

Máy chủ ảo hoá nhìn máy ảo như một hộp đen: nó biết mình đã cấp cho hộp đó bao nhiêu nhân CPU, bao nhiêu RAM, một ổ đĩa bao nhiêu byte và một thiết bị PCI nào. Nó không nhìn được vào bên trong hệ điều hành đang chạy trong hộp. Ba thứ người dùng quan tâm nhất lại nằm đúng phía bên trong đó.

Hình 1.4. Ba điểm mù của hypervisor và đường vòng duy nhất đi qua được: QEMU Guest Agent.

Câu 1 — “Máy này có địa chỉ IP nào?”

Máy chủ cấp cho máy ảo một card mạng ảo có địa chỉ MAC, rồi cắm card đó vào cầu nối vmbr0. Sau đó nó hết việc. Địa chỉ IP là do máy khách tự xin từ DHCP hoặc tự đặt tĩnh — hoàn toàn nằm trong hệ điều hành khách.

B43 gọi agent/network-get-interfaces qua Guest Agent, rồi lọc bỏ các card ảo do phần mềm bên trong tạo ra (loopback, Docker, VPN…) để chỉ giữ địa chỉ thuộc dải LAN sản xuất. Việc chọn đúng card không làm bằng cách đoán tên mà bằng cách so địa chỉ MAC của net0 trong file cấu hình với MAC mà agent báo về — dải nội bộ không đủ để phân biệt khi máy có nhiều card.

Câu 2 — “Ổ đĩa đã dùng bao nhiêu?”

LƯU Ý · CON SỐ 0 % GÂY HIỂU NHẦM NHIỀU NHẤT TRONG PROXMOX

status/current trả về disk: 0 cho mọi máy ảo QEMU đang chạy. Đó không phải lỗi: máy chủ chỉ thấy ổ đĩa như một khối byte đục, nó không đọc được hệ tập tin bên trong. Trang B43 bản đầu từng vẽ thẳng con số đó ra thành “0 %”, và người dùng đọc thành “ổ trống rỗng” — sai hoàn toàn.

▸ Nay B43 hỏi agent/get-fsinfo, bỏ các hệ tập tin ảo (tmpfs, overlay, squashfs…) rồi cộng lại.

▸ Không có agent ⇒ hiện “—” kèm tổng dung lượng và câu giải thích, không hiện 0 %.

▸ Container LXC thì có số thật mà không cần agent — máy chủ nhìn thẳng vào thư mục.

Câu 3 — “Driver card đồ hoạ đã chạy chưa?”

hostpci0 trong file cấu hình chỉ nói thiết bị đã được đưa vào máy. Nó hoàn toàn không nói hệ điều hành bên trong đã nạp được driver chưa, có bị lỗi chấm than vàng Mã 43 không, và quan trọng nhất: đã xin được giấy phép vGPU chưa. Máy chưa cấp phép vẫn chạy bình thường khoảng 20 phút rồi mới bị hạ hiệu năng xuống vài khung hình một giây — và không báo lỗi gì cả.

Câu trả lời đáng tin duy nhất là chạy nvidia-smi bên trong máy khách. B43 làm đúng như vậy qua agent/exec, rồi mã hoá kết quả thành màu của chip vGPU.

ĐÚNG THIẾT KẾ · VÌ SAO CHIP VGPU MÀU XÁM LÚC MỚI VÀO TRANG LÀ ĐÚNG

Phép hỏi máy khách chậm và có thể không bao giờ trả lời (máy Windows khai agent: 1 nhưng chưa cài dịch vụ bên trong). Nếu bảng chờ nó thì cả bảng đứng hình vì một máy. Vì vậy bảng vẽ ngay với trạng thái checking (xám), một luồng nền đi hỏi, và giao diện tự lấy lại sau 9 giây. Chụp màn hình ở giây thứ ba mà thấy xám thì đó không phải lỗi — hãy chờ đủ ít nhất 12 giây.

1.3 Ranh giới: những việc B43 CỐ Ý không làm

Một tài liệu đào tạo tốt phải nói rõ giới hạn, nếu không học viên sẽ đi tìm một nút không tồn tại rồi kết luận phần mềm hỏng.

Việc	Trạng thái	Lý do
Cấp địa chỉ IPv6 tự động	Chưa làm	Mạng LAN ba site hiện không có IPv6 từ nhà mạng. Muốn làm phải tự dựng dải ULA trên cầu nối vmbr0 của từng node và cho router quảng bá RA — đó là việc hạ tầng mạng, không phải việc của trang web.
Đặt lịch sao lưu định kỳ	Đã có (từ 18/09/2026)	Thẻ Lịch sao lưu tự động trên trang Sao lưu thêm/sửa/bật/tắt/chạy ngay/xoá job vzdump của Proxmox (mục 12.1). B43 vẫn không tự hẹn giờ — Proxmox chạy job, PBS tự cắt tỉa. Xem Phụ lục G.
Tường lửa theo từng Droplet	Chủ động không làm (18/09/2026)	Đã đánh giá cùng ổ phụ, card mạng/VLAN và token quyền hẹp (Phụ lục I); DŨNG chốt không làm. Lưu ý nếu ai đó bật tường lửa Proxmox: mặc định nó chặn cả HP1 ở site khác.
Gắn thêm ổ đĩa phụ (volume)	Chủ động không làm (18/09/2026)	Hiện chỉ hỗ trợ một ổ đĩa lúc tạo máy. Chia dữ liệu giữa các máy dùng Ổ chung (mục 10.3).
Đồ thị băng thông của node	Đã có	Sáu đồ thị theo thời gian trên mỗi thẻ máy chủ, kể cả nhiệt độ từng socket — mục 11.4.
Gửi cảnh báo qua Zalo	Cố ý không làm (18/09/2026)	Zalo Bot chính thức có nhưng không dùng; gửi “như người thật” chỉ có thư viện không chính thức, B43 sẽ phải giữ cookie Zalo của một người trong khi chính nó mở ra Internet. Dùng Telegram hoặc Slack — mục 15.5.
Nút xoá bản mẫu trong tab Bản mẫu	Cố ý không có	Bản mẫu win10-wp2-gpu đã bị xoá nhầm hai lần trong một ngày. Muốn xoá thì phải vào cây phả hệ và gõ lại mật khẩu.
Ô sửa smbios1 uuid / vmgenid	Cố ý không có	Cần đổi thật thì Proxmox có sẵn ở VM → Options → SMBIOS settings. Muốn máy con thật sự khác nhau thì đường đúng là sysprep bản mẫu, không phải sửa UUID từng máy.
Ghép hai node thành một cụm	Cố ý không làm	Hai máy chủ chạy độc lập (standalone). Ghép cụm Corosync sẽ kéo theo rủi ro treo toàn cụm khi một node mất điện hoặc bảo trì.

1.4 Bản đồ 12 trang — biết mình đang ở đâu

B43 là một ứng dụng một trang (SPA). Đổi trang chỉ là đổi phần #… trên thanh địa chỉ, không tải lại trang. Gõ một #hash lạ thì ứng dụng lặng lẽ quay về #/droplets chứ không báo lỗi — đó là thiết kế, không phải bug.

Hình 1.5. Mười hai trang của B43 (ba trang cuối thêm ngày 18/09/2026) và câu hỏi mà mỗi trang trả lời. Trang đăng nhập nằm NGOÀI bộ định tuyến này vì nó là một tệp HTML riêng.

Chương 2 — Kiến trúc kỹ thuật và những cơ chế ngầm

2.1 Hai máy chủ Proxmox ĐỘC LẬP — không phải một cụm

NGUY HIỂM · HỆ QUẢ PHẢI NHỚ SUỐT TÀI LIỆU

pve-wp2-01 và pve-wp2-02 là hai cài đặt Proxmox riêng biệt, không ghép cụm. Mọi khái niệm mà Proxmox coi là “nội bộ một máy chủ” đều phải nhân đôi.

▸ Dự án (Pool) phải được tạo giống hệt nhau trên cả hai node rồi B43 mới gộp lại khi hiển thị. Dự án chỉ có ở một node sẽ hiện cảnh báo kèm nút Tạo nốt.

▸ Kho local là kho RIÊNG của từng node. Tệp ISO tải lên node này, node kia không thấy.

▸ Không có di chuyển máy ảo trực tiếp (migrate) giữa hai node. Muốn chuyển thì đi đường sao lưu rồi khôi phục sang node kia.

2.2 Vé đăng nhập Proxmox và hình phạt 3 giây

proxmox_client.py đăng nhập vào Proxmox bằng tài khoản root@pam và nhận về một vé (ticket) sống 2 tiếng, kèm một mã CSRF. Mọi lời gọi sau đó mang theo vé đó.

Đo thật: Chi tiết quyết định trải nghiệm nằm ở chỗ vé hết hạn. Khi vé hết hạn, mỗi lời gọi ăn một mã lỗi 401 — và pveproxy của Proxmox cố tình trễ khoảng 3 giây mọi phản hồi 401 để chống dò mật khẩu. Một trang gọi cả chục API là cộng dồn thành hàng chục giây.

Khảo sát 28/08/2026 — bảng để qua đêm rồi mở lại

GET /api/nodes → 24 giây (vé đã hết hạn, mỗi lời gọi dính 3 s)

Sau khi thêm _ensure_ticket() gia hạn ở phút thứ 90

GET /api/nodes → 1,26 giây (không bao giờ chạm tới 401)

2.3 Bộ đệm hai tầng và bộ ngắt mạch — hai thứ rất dễ nhầm

Hình 2.1. Ý tưởng của bộ đệm: trình duyệt luôn nhận câu trả lời NGAY từ tầng đệm (mũi tên xanh), còn việc đi hỏi Proxmox lấy bản mới diễn ra ngầm ở nền (mũi tên nét đứt).

Hình 2.2. Bộ đệm làm trang nhanh. Bộ ngắt mạch làm một node tắt không kéo sập cả trang. Hai cơ chế tách rời, nằm ở hai tệp khác nhau, và hỏng theo hai kiểu khác nhau.

Tầng máy chủ — kiểu “trả bản cũ rồi làm mới ngầm”

cache.py không chặn người dùng lại để chờ dữ liệu mới. Dữ liệu quá hạn vẫn được trả về ngay lập tức, đồng thời một luồng nền đi lấy bản mới. Người dùng chỉ thật sự phải chờ đúng lần tải đầu tiên.

Họ khoá	Ví dụ và thời hạn	Bị xoá sau lệnh ghi?
live:	live:droplets 10 giây · live:nodes 10 giây · live:vgpu 45 giây · live:backups 20 giây	Có — tự động, do lớp trung gian _drop_cache_after_write
static:	static:images 900 giây · static:appliances 1800 giây · static:vgpunode 900 giây	Không

LƯU Ý · BÀI HỌC ĐÃ TRẢ GIÁ: /VGPU TỪNG NẰM NHẦM Ở STATIC:

Danh sách hồ sơ vGPU thì đứng yên thật, nhưng trường available bên trong nó đổi ngay khi một máy ảo bật hoặc tắt. Nằm ở static: nghĩa là không bị xoá sau lệnh ghi ⇒ bật tắt máy xong số chỗ trống không đổi. Quy tắc rút ra: cái gì đổi theo trạng thái máy thì phải ở live:.

Tầng trình duyệt

Hàm paint() nhớ lần vẽ trước của từng màn hình. Quay lại một tab đã xem là thấy nội dung tức thì, chỉ vẽ lại khi dữ liệu thực sự đổi. Kết quả đo được: thời gian đổi tab từ 0,9 – 7,3 giây xuống còn khoảng 5 mili-giây.

Bộ ngắt mạch — và ba điều hay hiểu sai

Bộ ngắt mạch nằm trong ProxmoxClient, hoàn toàn tách khỏi cache.py. Node nào vừa không với tới thì mọi lời gọi tới nó hỏng ngay tức khắc, không chạm vào mạng.

Số đo (29/08/2026, pve-wp2-01 đang tắt)	Trước	Sau
GET /api/nodes sau khi đã xoá đệm	3,02 giây	0,18 – 0,29 giây
Lời gọi thứ hai tới node đã chết	2,5 – 5 giây	0,0000 giây

2.4 Ba đường không đi qua REST API của Proxmox

Phần lớn giá trị của B43 nằm ở ba đường này, vì chúng lấy được thứ mà API chính thức không có.

Đường	Dùng để	Bẫy đã trả giá
SSH + qm monitor → screendump	Chụp ảnh màn hình máy ảo	Proxmox không có API chụp màn hình — /qemu/{vmid}/screenshot luôn trả 501. Và -f png không phải lúc nào cũng dùng được: QEMU trên pve-wp2-02 dựng không có libpng, nó từ chối bằng một dòng chữ trên màn hình điều khiển chứ không bằng mã thoát. Cách làm nay: thử PNG trước, không có tệp thì chụp PPM rồi tự đổi sang PNG.
QEMU Guest Agent (kênh virtio)	IP LAN, IP Public, dung lượng đĩa thật, nvidia-smi, cài driver vGPU	Proxmox 9 gãy với mọi ký tự ngoài ASCII khi gọi agent/file-write (500 Wide character in subroutine entry). Kịch bản có thông báo tiếng Việt nên chắc chắn dính ⇒ phải mã hoá base64 cả hai chiều.
Console proxy của B43	noVNC nhúng, không phải đăng nhập Proxmox	Bắt buộc mở qua HTTPS: phần xác thực VNC cần crypto.subtle, thứ không tồn tại ngoài ngữ cảnh bảo mật. Qua HTTP thì WebSocket rớt ngay sau lời chào RFB với mã 1006.

2.5 Cấu hình — bảng biến môi trường

Mọi thứ dưới đây đặt trong tệp .env nằm cạnh docker-compose.yml. Sửa .env xong phải docker compose up -d lotus_cloud — lệnh restart không nạp biến môi trường mới.

Biến	Ý nghĩa
B43_PVE_NODES	Mảng JSON khai báo các node: name, host, user, password. Thêm node = nối thêm một phần tử. Sai định dạng JSON thì ứng dụng vẫn khởi động, chỉ ghi cảnh báo và danh sách node rỗng.
B43_AUTH_USER / B43_AUTH_PASSWORD	Tài khoản đăng nhập vào chính trang B43. Bỏ trống mật khẩu = tắt xác thực, và trang sẽ hiện dải băng đỏ cảnh báo.
B43_AUTH_SECRET	Khoá ký cookie phiên. Để trống thì B43 tự sinh một lần rồi cất lại.
B43_STORAGE_MEDIA	Ánh xạ kho lưu trữ → loại ổ vật lý, để hiện chip Loại ổ. Giá trị thật đang dùng: pve-wp2-02 có local-lvm=nvme, local=nvme, vmstore=ssd, shared=hdd.
B43_NODE_WOL	Khai báo MAC + IP + relay_host của từng node để đánh thức từ xa. Không khai thì nút Send Wake-on-LAN không hiện.
B43_PUBLIC_HTTPS_URL	Địa chỉ HTTPS công khai. Nút Mở console tự nhảy sang đây khi trang đang chạy trên HTTP. Chưa đặt thì nó từ chối mở kèm lời giải thích, chứ không mở một cửa sổ chắc chắn hỏng.
B43_CONSOLE_PROXY	Đặt 0 để tắt hẳn console proxy.
B43_PROBE_INTERVAL	Nhịp luồng nền dò node đang tắt. Mặc định 20 giây.
B43_BREAKER_HOLD	Lưới an toàn cho bộ ngắt mạch phòng khi luồng nền chết. Mặc định 600 giây.
B43_START_TASK_WAIT	Chờ tối đa bao nhiêu giây cho tác vụ bật máy. Mặc định 12.
B43_AUTO_UNPIN_MACHINE	Đặt 0 để tắt cơ chế tự gỡ ghim +pveN (xem mục 7.6).
B43_GPU_SAMPLE_SEC	Nhịp lấy mẫu GPU dự phòng (mặc định 15 giây). Từ 16/09/2026 nhịp thật do nhịp chung quyết định — 10 giây khi có người xem, 60 giây khi không (mục 2.6) — nên biến này gần như không còn tác dụng.
B43_GPU_KEEP_HOURS	Giữ số liệu GPU bao lâu. Mặc định 24 giờ.
B43_METRICS_DB	Vị trí kho SQLite số liệu GPU. Mặc định /data/metrics.db.
B43_GPU_SAMPLER	Đặt 0 để tắt hẳn luồng nhịp chung — mất cùng lúc số liệu GPU, đồ thị nhiệt và cảnh báo chủ động (cảnh báo chạy trong chính luồng đó).
B43_TELEGRAM_BOT_TOKEN / B43_TELEGRAM_CHAT_ID	Nơi nhận cảnh báo qua Telegram. Để trống = không gửi. Thêm 18/09/2026.
B43_SLACK_WEBHOOK	URL Incoming Webhook của một kênh Slack. Thêm 18/09/2026.
B43_ALERT_WEBHOOK	URL nhận POST JSON (n8n, Discord…). Thêm 18/09/2026.
B43_ALERT_NHIET / B43_ALERT_KHO	Ngưỡng báo: nhiệt mỗi socket (mặc định 80 °C) và mức đầy kho / ổ hệ điều hành (mặc định 80 %).
B43_XOA_BAN_LUU_WAIT	Chờ tác vụ xoá bản sao lưu tối đa bao lâu trước khi trả lời. Mặc định 25 giây.
B43_PBS_DUONG_VAO	Câu chỉ đường vào giao diện PBS in trong thông báo lỗi khi xoá bản sao lưu bị từ chối vì thiếu quyền (mục 12.1).

GHI CHÚ · MÃ NGUỒN GẮN KẾT KIỂU CHỈ-ĐỌC

Thư mục B43_Lotus_Cloud/app được gắn vào container ở chế độ chỉ đọc (/app:ro), nên sửa mã xong chỉ cần docker compose restart lotus_cloud, không phải dựng lại ảnh. Riêng /data phải ghi được — đó là ổ chứa khoá SSH, sổ phả hệ lineage.json, lựa chọn vGPU vgpu_choice.json, màu dự án project_meta.json và kho số liệu GPU metrics.db.

▸ Từ 18/09/2026 /data còn giữ: totp.json (khoá 2FA, quyền 600), nhat_ky.jsonl (sổ Hoạt động, tự xoay vòng ở 5 MB), canh_bao.json (cảnh báo đang mở + lịch sử), ngu_dong.json (máy đang ngủ đông mà Proxmox không biết), uptime_cong.json (uptime cộng dồn qua lần tạm dừng). Mọi tệp trạng thái đều ghi qua tệp tạm rồi đổi tên — mất điện giữa chừng không để lại tệp rỗng.

2.6 Nhịp chung — một luồng lấy mẫu cho mọi nguồn số liệu

Trước 16/09/2026 mỗi nguồn số liệu có một đồng hồ riêng: nhiệt độ đọc qua SSH theo bộ đệm 8 giây, GPU có luồng nền 15 giây, CPU và bộ nhớ theo bộ đệm /api/nodes 10 giây. Ba đồng hồ chạy tự do nên mỗi ô số trên thẻ máy chủ là ảnh chụp của một thời điểm khác nhau, và không ai biết ô nào tươi hơn ô nào. Nay chỉ còn một luồng b43-nhip-chung:

Hình 2.3. Năm bước của một lượt nhịp chung. Bước 5 — đánh giá cảnh báo — thêm ngày 18/09/2026.

Điều	Đúng là	Nguồn
Nhịp	10 giây khi có người mở trang Hạ tầng, 60 giây khi không. Quá 25 giây không ai hỏi thì coi như trang đã đóng	main.py NHIP_XEM, NHIP_RANH, XEM_HET_HAN
Người vừa mở trang	Luồng đang ngủ nhịp 60 giây bị đánh thức ngay — đo được: chạy lại sau 0,0 giây	§16.25 tài liệu nội bộ
Tab trình duyệt bị ẩn	Không được tính là “đang xem”. Trình duyệt vẫn gọi API khoảng một lần mỗi phút từ tab ẩn; giao diện tự bỏ qua khi document.hidden	đo thật 16/09/2026
Hai thứ đứng ngoài nhịp	Ổ chung SMB (dò 2 phút/lần) và loại ổ SSD/HDD (lưu hw_cache.json) — gần như không đổi mà mỗi lần đo lại tốn SSH	—

LƯU Ý · BỘ ĐỆM CÓ TTL BẰNG ĐÚNG NHỊP GỌI THÌ MẤT MỘT NỬA SỐ MẪU

Đo thật 16/09/2026: giao diện gọi 10 giây/lần, bộ đệm /api/nodes cũng sống 10 giây — gần một nửa số lượt rơi đúng lúc bộ đệm còn hạn nên không đo gì. Khoảng cách thật giữa các mẫu là 19 giây trong khi mọi chú thích trong mã đều ghi 10. Bài học chung: TTL phải nhỏ hơn hẳn nhịp gọi. Chi tiết ở Phụ lục H.2.

2.7 Bộ test tự động và nén đường truyền

Trước 18/09/2026 B43 không có một test tự động nào — mọi lỗi kiểu “chạy được, không báo lỗi” chỉ lộ khi có người tình cờ nhìn. Nay thư mục tests/ có hai tầng:

Lệnh (chạy trong B43_Lotus_Cloud/)	Kiểm gì	Kết quả 19/09/2026
python3 -m pytest tests/ -q	Đơn vị (2FA, sổ Hoạt động, lịch sao lưu, cảnh báo) + cấu trúc mã. Không cần mạng — chạy trước mọi lần docker restart lotus_cloud	45 đạt
B43_SMOKE=1 python3 -m pytest tests/test_smoke_live.py -q	Chỉ đọc trên B43 đang chạy: chưa đăng nhập bị chặn, từng endpoint trả đúng mã và khoá JSON, nén đúng chỗ. Tự qua 2FA	16 đạt

NGUY HIỂM · LỖI MÀ PY_COMPILE KHÔNG BẮT ĐƯỢC — ĐÃ LÀM CONTAINER KHỞI ĐỘNG LẠI LIÊN TỤC

main.py dài hơn 10.000 dòng, và hàm bộ đệm cached chỉ được định nghĩa ở khoảng dòng 800. Một endpoint khai phía trên dòng đó mà gắn @cached thì Python ném NameError ngay lúc nạp mô-đun, uvicorn chưa kịp lắng nghe, Docker thấy container không khoẻ và khởi động lại mãi. Cú pháp hoàn toàn đúng nên py_compile im lặng. Nay test_decorator_khong_dung_truoc_khi_dinh_nghia quét cây cú pháp và chỉ đúng tên hàm, số dòng.

Cùng đợt, B43 nén mọi phản hồi trên 1 KB bằng gzip. Đo thật: app.js 491,6 → 147,8 KB, styles.css 162,6 → 38,1 KB, /api/nodes 22,0 → 4,4 KB — đáng kể khi mở trang qua Internet. Cố ý không nén bốn nhóm đường: tải driver vGPU (tệp nhị phân sẵn), chuyển tiếp Proxmox /api2/, console /novnc/ và /console, ảnh màn hình PNG.

Chương 3 — Ba workpool, đường hầm VPN và quy tắc đặt cổng

Hạ tầng Great Lotus trải trên ba địa điểm vật lý, nối với nhau bằng đường hầm VPN IPSec lưới toàn phần (full-mesh) giữa ba bộ định tuyến TP-Link Omada ER605.

Hình 3.1. Ba workpool và đường hầm IPSec. Có VPN rồi thì gọi máy site khác bằng IP LAN và cổng thật, KHÔNG vòng qua tên miền động cùng cổng chuyển tiếp.

Workpool	Dải mạng	Thiết bị trọng yếu	Cổng dịch vụ
WP1 — trụ sở điều hành	172.16.10.0/24	HP1 172.16.10.220 (Ubuntu, chạy Docker Compose)	20430 B43 · 20350/20351 B35 · 20440 máy cấp phép vGPU · 80/443 Caddy
WP2 — cụm tính toán	172.16.20.0/24	pve-wp2-01 .101 · pve-wp2-02 .102 · White NAS (NAS2)	8006 Proxmox · 22 SSH · 5000/5001 DSM · 445 SMB · 2049 NFS
WP3 — trạm làm việc	172.16.30.0/24	WP3-PC1 172.16.30.101	3389 RDP · 22 OpenSSH
Bộ định tuyến	.1 của mỗi dải	TP-Link Omada ER605 × 3	1024 giao diện web quản trị

GHI CHÚ · QUY TẮC ĐẶT CỔNG CỦA TOÀN HỆ THỐNG

Container tên Bxx ⇒ địa chỉ nội bộ Docker 114.114.114.xx ⇒ cổng trên máy chủ 20xx0. Ví dụ B43 ⇒ 114.114.114.43 ⇒ 20430; B35 ⇒ 114.114.114.35 ⇒ 20350 (xem qua noVNC) và 20351 (điều khiển WebDriver). Biết một cái là suy ra được hai cái còn lại.

NGUY HIỂM · NGUYÊN TẮC ZERO-EXPOSURE

Cổng 20430 của B43 và cổng 8006 của các máy chủ Proxmox tuyệt đối không được mở NAT ra Internet. Lý do không chỉ là “cẩn thận cho chắc”:

▸ Console proxy của B43 chuyển tiếp phiên root@pam của chính B43 cho bất kỳ trình duyệt nào mở được B43. Ai vào được B43 là điều khiển được máy ảo ở mức quản trị.

▸ Cổng 20350/20351 của B35 mở ở 0.0.0.0 và không có xác thực — chỉ để trong LAN.

▸ Truy cập từ ngoài phải đi qua VPN, hoặc qua tên miền HTTPS đã cấu hình trên Caddy (b43.lotuscloud.lotus1104.synology.me) với xác thực đầy đủ.

3.1 Bẫy hairpin NAT khi mở console trong LAN

Trong mạng nội bộ, tên miền b43.lotuscloud.lotus1104.synology.me phân giải ra địa chỉ WAN và thường không đi ngược vào được (hiện tượng hairpin NAT). Caddy đã mở cổng 443 ngay trên HP1, nên cách chữa đơn giản là trỏ thẳng tên miền đó vào IP LAN. Chứng chỉ vẫn hợp lệ vì nó gắn với TÊN, không phải với IP.

# Thêm vào tệp hosts của máy người dùng

172.16.10.220 b43.lotuscloud.lotus1104.synology.me

Chương 4 — Hai node tính toán và tầng lưu trữ

4.1 Thông số thật của hai node

Số liệu dưới đây đọc trực tiếp từ GET /api/nodes lúc biên soạn, không phải lấy từ tài liệu cũ.

Hạng mục	pve-wp2-01	pve-wp2-02
Địa chỉ	172.16.20.101	172.16.20.102
Trạng thái lúc chụp	offline (đang tắt)	online, uptime ~2 giờ
CPU	8 luồng (theo tài liệu kỹ thuật nội bộ)	2 × Intel Xeon E5-2673 v3 @ 2,40 GHz — 2 socket × 24 nhân = 48 luồng
RAM	—	94 GB (101.104.029.696 byte), đang dùng ~19 GB
Proxmox	—	9.2.2, nhân 6.14.11-9-pve, khởi động EFI, Secure Boot tắt
Đồ hoạ	Intel UHD Graphics 620 — công nghệ GVT-g (i915-GVTg_V5_4 / _V5_8)	NVIDIA GeForce GTX 1660 Ti 6 GB — chạy vgpu_unlock
Kho lưu trữ	local (HDD) · local-zfs (HDD)	local (dir/NVMe) · local-lvm (lvmthin/NVMe) · vmstore (lvmthin/SSD SATA)

Hiện trạng ngày 19/09/2026 — chỉ còn một máy chủ, đã đổi phần cứng

Bảng trên đúng cho ngày 07/09. Từ đó pve-wp2-02 đã đổi tên thành pve-001, chuyển sang WP3 và thay CPU, thêm RAM; pve-wp2-01 không còn khai trong B43 (trang Hạ tầng ghi “1 máy chủ đang khai báo”). Số dưới đây đọc trực tiếp trên node bằng lscpu, free -g, pveversion và từ thẻ máy chủ của B43:

Hạng mục	pve-001 (nhãn hiển thị WP3_PVE1)
Địa chỉ	172.16.30.102 (WP3)
CPU	2 × Intel Xeon E5-2696 v4 @ 2,20 GHz — 2 socket × 22 nhân × 2 luồng = 88 luồng
RAM	125 GiB theo free -g (thẻ B43 làm tròn thành 126 GB)
Proxmox	9.2.2, nhân 6.14.11-9-pve — không đổi
Đồ hoạ	Vẫn GTX 1660 Ti 6 GB chạy vgpu_unlock, chia 6 × 1 GB
Ngưỡng nhiệt CPU	max 83 °C (tự hạ xung) · crit 85 °C (phần cứng cắt điện) — đọc từ chính con chip, xem mục 11.5

LƯU Ý · HAI NODE KHÔNG GIỐNG NHAU — ĐỪNG DÙNG CHUNG MỘT BỘ TIÊU CHÍ

pve-wp2-01 dùng Intel GVT-g, pve-wp2-02 dùng NVIDIA vGPU. Độ tin cậy của số liệu hai bên khác hẳn nhau, nên vgpu_facts.kind_of() tách hai loại ngay từ đầu.

▸ Intel GVT-g: available_instances đọc thẳng từ sysfs của nhân i915 — số đó vốn đã đúng, không phải tính lại gì. Và GVT-g không có ràng buộc “cùng cỡ”.

▸ NVIDIA: mọi số driver báo về đều sai một cách có hệ thống — xem mục 5.3.

▸ Kho lưu trữ cũng khác: pve-wp2-01 có local-zfs, pve-wp2-02 thì không.

4.2 Bảng kho lưu trữ đọc được từ hệ thống thật

Hình 4.1. Bảng Kho lưu trữ trên trang Hạ tầng. Sáu cột: Tên · Loại · Loại ổ · Health · Đã dùng/Tổng · Mức dùng. Bấm vào một dòng sẽ mở bảng bóc tách chi tiết.

Kho	Loại Proxmox	Ổ vật lý	Health	Đã dùng / Tổng	Chứa gì
local	dir	NVMe	94 %	23 / 66 GB (34 %)	iso, snippets, vztmpl, import, backup
local-lvm	lvmthin	NVMe	94 %	0 / 137 GB (0 %)	images, rootdir
vmstore	lvmthin	SSD SATA	78 %	74 / 466 GB (16 %)	images, rootdir

Cột Health là chỉ số sức khoẻ đọc ngược từ SMART của ổ vật lý nằm dưới kho đó. Đường truy ngược là: kho → nhóm ổ luận lý (LVM) → phân vùng → thiết bị khối. Việc dò này chạy ngầm, không nằm trong lần trả về đầu tiên của _node_summary, để một ổ trả lời chậm không làm cả trang Hạ tầng đứng hình.

GHI CHÚ · CẬP NHẬT 11/09/2026: BẢNG CÓ THÊM DÒNG PBS, BÊN DƯỚI CÓ THÊM MỤC Ổ CHUNG

Từ ngày này bảng có bốn dòng: local 23/66 GB · local-lvm 2,4/137 GB · pbs 21/635 GB · vmstore 79/466 GB. Dòng pbs ghi HDD, Health 95%* — điểm của ổ sdc. Ổ chung 3,0 TB và ổ nhanh 457 GB không phải kho Proxmox nên nằm ở mục Ổ chung ngay dưới bảng. Mọi thanh Mức dùng có vạch đỏ ở 80 %. Xem Phụ lục G.3.

4.3 Vì sao “Đã dùng” không bao giờ khớp tổng cột “Dung lượng”

Đây là câu hỏi được hỏi nhiều nhất khi ai đó lần đầu nhìn bảng kho lưu trữ, và lệch là đúng thiết kế. Backend trả về trường reconcile.kind để giao diện chọn đúng câu giải thích; giao diện không được tự suy từ dấu của hiệu số.

Hình 4.2. Hai kiểu lệch ngược chiều nhau. Nhầm chúng với nhau là đi tìm một lỗi không tồn tại.

reconcile.kind	Khi nào	Nghĩa và số đo thật
thin	Kho lvmthin / zfspool / rbd — tổng khai báo lớn hơn đã dùng	Cấp phát mỏng. base-9002-disk-0 khai 32 GB, thực chiếm 19 GB — 42,6 % ổ là vùng rỗng. Không mất gì cả.
shared-fs	Kho dir / nfs / cifs — đã dùng lớn hơn tổng các mục	Kho nằm chung phân vùng với hệ điều hành ⇒ Proxmox báo mức dùng của cả phân vùng. Đo thật trên local của pve-wp2-02: báo 19 GB, nội dung kho chỉ 12,4 GB — 7,3 GB là chính Proxmox.
match	Khớp	Không hiện chú thích nào.
unknown	Kho không dùng chung chỗ mà vẫn dư	Đây mới là bất thường thật, đáng đăng nhập vào máy chủ xem.

Hình 4.3. Bảng bóc tách khi bấm vào một dòng kho: đã dùng, còn trống, kiểu kho, và danh sách từng mục nằm trong kho đó.

4.4 Chọn kho nào cho việc gì

Hình 4.4. Ba tầng lưu trữ: càng lên trên càng nhanh, càng xuống dưới càng nhiều dung lượng. Ngày 07/09 chỉ còn hai tầng trên vì ổ HDD cũ hỏng (Phụ lục A); từ 11/09/2026 tầng HDD có lại — ổ 4 TB SMR và 500 GB CMR, dùng làm kho sao lưu và ổ chung, không đặt đĩa máy ảo (Phụ lục G).

Việc	Kho nên chọn	Lý do
Ổ đĩa hệ điều hành của máy ảo cần I/O cao (cơ sở dữ liệu, đệm)	local-lvm (NVMe)	Cấp phát mỏng trên NVMe. Tốc độ cao nhất trong hệ thống.
Máy ảo văn phòng, máy chạy trình duyệt, bản mẫu	vmstore (SSD SATA)	Dung lượng lớn hơn nhiều (466 GB) mà vẫn là ổ thể rắn.
Tệp ISO, mẫu container, đoạn snippets cloud-init	local	Đây là kho duy nhất bật các kiểu nội dung đó. Riêng từng node — tải lên node này node kia không thấy.
Bản sao lưu	pbs (từ 11/09/2026)	Tự động 23:30 mỗi đêm, chống trùng lặp, Proxmox không xoá được. Nằm trên chính node ⇒ tính tới chuyện mất node thì vẫn phải có bản ở NAS. Xem Phụ lục G.5.
File dùng chung giữa các máy ảo	\\10.77.0.10\share · \\10.77.0.10\fast	Không phải kho Proxmox — là ổ mạng SMB, nên không hiện trong ô chọn kho nào. Xem Phụ lục G.4.

LƯU Ý · KHO LOCAL ĐANG Ở MỨC 34 % VÀ CHỨA CẢ BẢN SAO LƯU

local là kho kiểu dir nằm chung phân vùng với hệ điều hành Proxmox (66 GB tổng). Đổ bản sao lưu VZDump vào đó là con đường ngắn nhất tới cảnh đầy ổ hệ thống, và ổ hệ thống đầy thì Proxmox ngừng ghi được cả log lẫn cấu hình. Với bản sao lưu dài hạn, đích đúng là kho NFS trên White NAS.

Chương 5 — Card đồ hoạ ảo — phần dễ hiểu sai nhất

5.1 Bức tranh tổng thể

Trên pve-wp2-02 có một card NVIDIA GeForce GTX 1660 Ti 6 GB. Đây là card chơi game, về nguyên bản NVIDIA không cho phép chia lát cho nhiều máy ảo. Bản vá vgpu_unlock làm cho driver nhìn nó như một Quadro RTX 6000 — card chuyên nghiệp có tính năng đó.

Hình 5.1. Cách chia đang áp dụng thật trên hệ thống: 6 lát × 1 GB, ba lát đang được ba máy giữ.

NGUY HIỂM · CÁI GIÁ CỦA VIỆC GIẢ TRANG: MỌI CON SỐ DRIVER BÁO VỀ ĐỀU SAI

Driver tưởng nó đang phục vụ một card 24 GB, nên nó khai max_instance và available theo cỡ đó. Đọc thẳng những con số ấy ra giao diện là nói dối người dùng.

▸ Driver liệt kê 18 hồ sơ cho card này — đó là danh mục của Quadro RTX 6000 nó giả trang, không phải danh sách chọn được.

▸ Lọc lần 1 — bỏ hồ sơ lớn hơn VRAM thật: 8Q/12Q/24Q đòi 8–24 GB, card chỉ có 6 GB ⇒ không bao giờ khởi động được. Còn 12 hồ sơ.

▸ Lọc lần 2 — bỏ hồ sơ trái cỡ với lát đang khoá. Còn 3 hồ sơ.

▸ Số chỗ còn lại tính bằng HIỆU, vì hai số lệch cùng một lượng nên hiệu thì đúng: đang giữ = max_instance(driver) − available(driver), rồi còn lại = số lát thật − đang giữ.

5.2 Quy tắc “cùng cỡ” (Homogeneous) — khoá theo CỠ, không theo mã hồ sơ

Driver báo Homogeneous vGPUs: 1, nghĩa là mọi vGPU trên cùng một card vật lý phải cùng cỡ khung đệm. Máy ảo đầu tiên lấy cỡ nào thì cả card khoá vào cỡ đó cho tới khi mọi máy đang giữ card đều tắt.

Điểm tinh tế mà rất nhiều người hiểu sai: khoá theo CỠ, không theo mã hồ sơ. Đo thật trên pve-wp2-02 khi một máy đang giữ một lát 2 GB:

nvidia-256 (1Q) avail=0 <- khac co => khoa

nvidia-257 (2Q) avail=11 <- cung co => con cho

nvidia-436 (2B) avail=11 <- cung 2 GB, KHAC dong => van mo

nvidia-438 (2A) avail=11 <- nt

nvidia-259 (4Q) avail=0 <- khac co => khoa

Vì vậy khi hạ tầng đã chốt cỡ 1 GB, ô chọn vGPU ở trang Tạo Droplet vẫn còn ba dòng chứ không phải một — 1A, 1B, 1Q cùng 1 GB nhưng khác dòng sản phẩm. Chặn hai dòng kia là chặn oan.

5.3 Ba dòng hồ sơ vGPU và chọn dòng nào

Ô Kiểu vGPU ở trang Cấu hình máy chủ cho chọn ba dòng, và ba dòng này khác nhau về tính năng, không chỉ về tên:

Dòng	Tên trên giao diện	Mã thật	Dùng cho
A	Phát ứng dụng	nvidia-437	Máy chủ ứng dụng, phát phần mềm cho nhiều người dùng cùng lúc.
B	Máy để bàn ảo	nvidia-435	Máy nhân viên văn phòng, duyệt web, ứng dụng nội bộ.
Q	Máy trạm đồ hoạ	nvidia-256	Có CUDA/OpenCL, dựng hình 3D chuyên nghiệp, nhiều màn hình độ phân giải cao. Đây là dòng đang dùng trên hệ thống.

MẸO · NẾU BẠN ĐỊNH CHẠY TÍNH TOÁN GPU HAY AI TRONG MÁY ẢO

Chỉ dòng Q có CUDA. Chọn nhầm sang A hoặc B thì máy vẫn có card, vẫn dựng hình được, nhưng mọi thư viện dựa trên CUDA sẽ báo không tìm thấy thiết bị — và thông báo lỗi lúc đó không hề nhắc gì tới dòng hồ sơ.

5.4 VRAM máy ảo thấy KHÔNG bằng VRAM bạn cấp

Hình 5.2. Bảng “Cấu hình đang áp dụng” ở trang Cấu hình máy chủ — bảng này trả lời một câu hỏi mà không tài liệu nào của Proxmox nói tới.

Hồ sơ	VRAM máy ảo thấy	GPU giữ lại	Tổng mỗi vGPU
nvidia-256	928 MiB	96 MiB	1024 MiB

96 MiB bị GPU giữ lại cho cấu trúc quản lý của chính lát vGPU đó. Người dùng bên trong máy khách chạy nvidia-smi sẽ thấy 928 MiB, không phải 1024 MiB — và đó là bình thường. Không có bảng này thì mỗi lần ai đó nhìn nvidia-smi lại đi báo “cấp thiếu VRAM”.

LƯU Ý · KHOÁ MISMATCH — TRẠNG THÁI CHẠY ĐƯỢC NHƯNG SAI CỠ

Khi VRAM trong file cấu hình lệch VRAM máy khách báo về quá 64 MiB, API trả thêm khoá mismatch. Nó nghĩa là máy khách vẫn đang chạy driver của lần gắn card trước đó, chưa tắt bật lại sau khi đổi hồ sơ vGPU. Rất dễ bỏ qua vì chip vẫn xanh.

5.5 Gắn card mới chỉ là bước một

NGUY HIỂM · GẮN VGPU XONG PHẢI TẮT RỒI BẬT LẠI — REBOOT KHÔNG ĐỦ

Cấu hình hostpci0 chỉ được đọc lúc dựng tiến trình QEMU. Máy đang chạy thì bên trong Windows không có thiết bị nào cả — Device Manager chỉ thấy Microsoft Basic Display Adapter, và nút cài driver trở thành vô nghĩa. Khởi động lại từ bên trong hệ điều hành là chưa đủ; QEMU phải dựng lại tiến trình.

Sau khi máy đã thật sự thấy thiết bị, còn 5 bước nữa: tải bộ driver GRID đúng phiên bản, cài, cấu hình máy cấp phép, xin giấy phép, kiểm chứng. Sai một bước thì card chạy khoảng 20 phút rồi tụt xuống ~3 khung hình/giây mà không báo lỗi gì. Nút Cài driver vGPU ở tab Tổng quan làm cả 5 bước đó (xem mục 9.4).

Ràng buộc phiên bản đọc từ tên thư mục kho driver, không cho người dùng chọn:

nvgpu_NVIDIA-GRID-Linux-KVM-550.163.02-550.163.01-553.74

Bẫy đã trả giá	Sự thật
500 Wide character in subroutine entry khi gọi agent/file-write	Proxmox 9 gãy với mọi ký tự ngoài ASCII. Kịch bản có thông báo tiếng Việt nên chắc chắn dính ⇒ phải mã hoá base64 cả hai chiều (ghi kịch bản và đọc log).
Depends: linux-headers but none of the choices are installable	Header đúng phiên bản đã cài rồi. Debian 13 bỏ gói ảo linux-headers mà gói .deb của NVIDIA đòi (Debian 12 còn có) ⇒ không sửa được bằng cài thêm gói, phải lùi sang bản .run.
Máy tạo từ ảnh cloud không có agent	--agent enabled=1 mới chỉ tạo cổng phía máy chủ. Ảnh Debian genericcloud không kèm qemu-guest-agent ⇒ phải nhét đoạn cloud-init cài sẵn.
Trình cài .run chết bằng SIGBUS	Nó giải nén vào /tmp, mà ảnh cloud để /tmp là tmpfs 2 GB nằm trong RAM. Gói 300–600 MB làm tràn ⇒ phải thêm --tmpdir=/var/tmp.

ĐÚNG THIẾT KẾ · ĐÃ KIỂM ĐẦU-CUỐI (29/08/2026)

Ảnh Debian 13 trống → bấm một nút → GRID RTX6000-2Q, 2048 MiB, driver 550.163.01 + License Status: Licensed (Expiry: 2026-11-26). Toàn bộ mất khoảng 6 phút.

Chương 6 — Đăng nhập và khung ứng dụng

6.1 Trang đăng nhập /login.html

Trang đăng nhập là một tệp HTML hoàn toàn độc lập, nằm NGOÀI bộ định tuyến của ứng dụng chính. Nó cố ý không nạp styles.css và app.js.

MẸO · VÌ SAO CỐ Ý KHÔNG NẠP TỆP GIAO DIỆN CHUNG

Cả hai tệp đó nằm sau lớp xác thực. Nạp chúng ở đây sẽ tạo ra hai yêu cầu bị chặn 401 mỗi lần mở trang đăng nhập, và trang tự vỡ hình đúng lúc người dùng cần nó nhất. Vài chục dòng CSS viết thẳng trong trang rẻ hơn nhiều.

Hình 6.1. Trang đăng nhập với sáu thành phần được đánh số.

Số	Mã HTML	Thành phần	Giải thích đầy đủ
①	input#u	Tên đăng nhập	Giá trị mặc định admin, khai trong biến B43_AUTH_USER. Ô có thuộc tính autofocus nên con trỏ đã sẵn ở đây khi trang mở; và autocomplete="username" để trình quản lý mật khẩu của trình duyệt nhận ra.
②	input#p	Mật khẩu	Tương ứng biến B43_AUTH_PASSWORD. Khi đăng nhập sai, ô này tự bị xoá trắng và tự lấy lại con trỏ — người dùng gõ lại được ngay, không phải bấm chuột.
③	input#r	Ghi nhớ máy này trong 30 ngày	Mặc định đã tích sẵn. Có tích: cookie b43_session sống 30 ngày. Bỏ tích: cookie huỷ ngay khi đóng trình duyệt. Chọn bỏ tích khi dùng máy chung.
④	button#b	Nút Đăng nhập	Gửi POST /api/login kèm JSON. Trong lúc chờ, nút chuyển sang disabled, đổi chữ thành Đang kiểm tra… và con trỏ đổi thành đồng hồ cát — chống bấm đúp gửi hai lần.
⑤	.brand	Nhãn hiệu Lotus Cloud	Kèm dòng phụ “Bảng điều khiển máy ảo Proxmox”. Trang này theo đúng ba trạng thái giao diện của ứng dụng chính (theo hệ thống / sáng / tối), đọc từ khoá localStorage['lotus-theme'] trước khi thân trang được vẽ để không loé sáng một nhịp rồi mới tối.
⑥	.foot	Dòng nhắc chân trang	“Trang này điều khiển máy ảo thật. Chỉ dùng trong mạng nội bộ.” — một lời nhắc cố ý, không phải trang trí.

Khi đăng nhập sai

Hình 6.2. Hộp lỗi #err chỉ hiện khi có lỗi thật. Ô mật khẩu đã tự xoá trắng.

GHI CHÚ · HAI CHI TIẾT AN TOÀN ẨN TRONG TRANG ĐĂNG NHẬP

▸ Tham số next được kiểm lại ở phía trình duyệt. Máy chủ gắn nó vào khi chuyển hướng, nhưng trang vẫn tự kiểm: chỉ chấp nhận đường dẫn nội bộ. Nhận bừa thì một liên kết dạng /login.html?next=https://trang-gia-mao sẽ đá người dùng sang trang khác ngay sau khi họ vừa gõ mật khẩu.

▸ Phần #… được vá lại thủ công. Trình duyệt không gửi phần sau dấu # lên máy chủ, nên lần chuyển hướng 302 chỉ biết được /. Trang tự ghép lại #/droplet/… mà người dùng đang mở, để đăng nhập xong họ quay về đúng chỗ.

Khi xác thực hai lớp đang bật (từ 18/09/2026)

Sau khi người quản trị bật 2FA ở trang Bảo mật (mục 15.3), trang đăng nhập có thêm bước thứ hai. Người dùng vẫn gõ tên và mật khẩu như cũ; mật khẩu đúng thì máy chủ trả 401 kèm cờ need_totp, và ô mã mới hiện ra — mật khẩu được giữ nguyên, không phải gõ lại.

Hình 6.3. Bước thứ hai của lần đăng nhập: mật khẩu đã đúng, trang chờ mã 6 số từ điện thoại.

Số	Mã HTML	Thành phần	Giải thích
①	input#u	Tên đăng nhập	Như trước, không đổi.
②	input#p	Mật khẩu	Giữ nguyên giá trị đã gõ — chỉ ô mã là việc còn lại.
③	#totpBox	Khối Mã xác thực	Ẩn cho tới khi máy chủ trả need_totp. Dòng phụ “6 số, từ ứng dụng trên điện thoại”. Hộp đỏ phía trên ghi “Nhập mã xác thực từ ứng dụng trên điện thoại.” — đó là lời nhắc, không phải báo lỗi.
④	input#c	Ô mã	inputmode=numeric (điện thoại bật bàn phím số) và autocomplete=one-time-code (điện thoại tự gợi ý mã vừa nhận). Con trỏ tự nhảy vào đây.
⑤	button#b	Đăng nhập	Gửi lại cả mật khẩu và mã trong cùng một lời gọi.

LƯU Ý · MÃ SAI TÍNH NHƯ MẬT KHẨU SAI — NHƯNG BƯỚC CHỜ MÃ THÌ KHÔNG

Gõ sai mã, máy chủ trả “Mã xác thực không đúng hoặc đã dùng rồi. Chờ mã mới rồi thử lại.” và cộng một lần sai vào cùng ô đếm chống dò của mật khẩu: từ lần sai thứ 5 là bị bắt chờ lâu dần. Còn bước đầu (đúng mật khẩu, chưa có mã) không bị tính là sai.

▸ Mã đã dùng là hết trong cùng bước 30 giây — chống phát lại. Vừa dùng mã để bật 2FA xong mà đăng nhập ngay bằng đúng mã đó sẽ bị từ chối: đợi mã kế tiếp.

▸ Trong sổ Hoạt động, một lần đăng nhập 2FA thành công hiện hai dòng: dòng đầu ghi Đăng nhập thất bại — Sai (chính là bước chờ mã), dòng sau Đăng nhập — OK. Dòng đầu không phải có người dò mật khẩu — xem mục 15.4.

6.2 Khung ứng dụng — thanh bên, thanh trên, chân thanh bên

Hình 6.4. Toàn bộ khung ứng dụng, chụp ngày 07/09/2026: mười tám thành phần cố định, hiện trên MỌI trang. Từ 18/09 thanh bên có thêm hai mục — xem Hình tiếp theo.

Số	Mã HTML	Thành phần	Giải thích
①	.sidebar-brand	Nhãn hiệu	Lotus Cloud. Không phải nút bấm.
②	a[data-route=droplets]	Droplets	Trang mặc định. Bảng gộp máy ảo và container của mọi node.
③	#navProjects + #navFold	Danh sách dự án con	Mỗi dự án là một mục con của Droplets, kèm chấm màu và số máy. Bấm vào chỉ thấy máy của dự án đó (#/droplets/<tên>). Mục Chưa xếp chỉ hiện khi thật sự còn máy chưa thuộc dự án nào. Nút v gấp danh sách lại, và lựa chọn đó được nhớ.
④	a[data-route=marketplace]	Marketplace	13 ứng dụng dựng sẵn + tìm trên Docker Hub. Trang này KHÔNG tạo máy — xem mục 12.4.
⑤	a[data-route=projects]	Dự án	Quản lý nhóm logic. Nền phía dưới là Pool của Proxmox.
⑥	a[data-route=nodes]	Hạ tầng	Sức khoẻ node, kho lưu trữ, đánh thức và tắt nguồn máy chủ.
⑦	a[data-route=backups]	Sao lưu	Bản sao lưu VZDump của toàn cụm.
⑧	a[data-route=templates]	Cấu trúc/bản mẫu	Đứng ngay dưới Sao lưu vì hai thứ trả lời cùng một câu hỏi: “tôi dựng lại được từ đâu?”.
⑨	a[data-route=sshkeys]	SSH Keys	Kho khoá công khai dùng chung.
⑩	a[data-route=serverconfig]	Cấu hình máy chủ	Chọn cách dùng card đồ hoạ và chia lát vGPU.
⑪	#whoBox / #logoutBtn	Người đang đăng nhập + Đăng xuất	Ẩn hoàn toàn khi trang chạy ở chế độ không bật xác thực; lúc đó thay vào là dải băng đỏ #noAuthBar ở đầu trang.
⑫	#themeToggle	Đổi giao diện	Vòng ba trạng thái: Theo hệ thống → Sáng → Tối. Nhớ trong localStorage['lotus-theme'], dùng chung với trang đăng nhập.
⑬	#sidebarStatus	Trạng thái kết nối	“N node kết nối”, tự cập nhật 30 giây một lần. Đây là chỗ nhìn đầu tiên khi nghi một node đã rớt.
⑭	#pageTitle / #pageSub	Tiêu đề trang	Đổi theo route. Khi kiểm thử tự động, đây là mốc đáng tin để xác nhận đã sang đúng trang.
⑮	#pageHelpBtn	? Hướng dẫn	Mở cẩm nang của chính trang đang xem (khoá page.<route> trong help.js).
⑯	#refreshBtn	↻ Làm mới	Xoá CẢ HAI tầng đệm rồi vẽ lại: gọi POST /api/cache-clear ở máy chủ và forgetViews() ở trình duyệt. Đây là công cụ số một khi nghi số liệu cũ.
⑰	a.btn-primary[href=#/create]	Tạo Droplet	Cố định ở góc trên bên phải, hiện trên mọi trang. Vì thế thanh bên cố ý không có mục cùng chức năng — hai lối vào giống hệt nhau cách nhau vài xăng-ti-mét chỉ làm thanh bên dài thêm.
⑱	table.table-droplets	Vùng nội dung	Phần duy nhất thay đổi khi đổi trang.

Hai mục mới trên thanh bên, và tên người dùng thành liên kết (18/09/2026)

Hình 6.5. Thanh bên ngày 19/09/2026: Cảnh báo và Hoạt động đứng sau Cấu hình máy chủ; tên admin ở chân thanh bên bấm được.

Số	Mã HTML	Thành phần	Giải thích
①	a[href=#/alerts] + #navCanhBao	Cảnh báo	Kèm số đỏ = số cảnh báo đang mở; không có cảnh báo nào thì số ẩn hẳn. Số được cập nhật cùng nhịp 30 giây của ô trạng thái kết nối, nên đang ở trang nào cũng thấy. Có cảnh báo chưa xem thì số có thêm quầng đỏ nhạt (is-moi). Mục 15.5.
②	a[href=#/activity]	Hoạt động	Sổ ai làm gì trên B43 và tác vụ Proxmox. Mục 15.4.
③	#whoName	Tên người đang đăng nhập	Nay là liên kết sang trang Bảo mật (#/security) — cố ý không thêm mục riêng trên thanh bên cho một trang chỉ mở vài lần trong đời. Mục 15.3.

Giao diện tối

Hình 6.6. Chế độ Tối. Bảng màu nhãn dự án được khai riêng cho từng giao diện để nhãn luôn đọc được trên cả nền sáng lẫn nền tối.

6.3 Hướng dẫn tại chỗ — hai tầng, cố ý tách

Thao tác	Hiện gì	Dùng khi
Rê chuột vào chấm ?	Một câu ngắn	Đang làm dở, chỉ cần biết ô này là gì
Bấm vào chấm ?	Cửa sổ dài, có lệnh chép được	Muốn hiểu tại sao
Nút ? Hướng dẫn trên thanh trên	Hướng dẫn của cả trang đang xem	Mới vào một trang lạ

Hình 6.7. Cửa sổ hướng dẫn cấp trang, mở từ nút ? Hướng dẫn.

Hình 6.8. Cửa sổ hướng dẫn cấp ô, mở bằng cách BẤM vào chấm ? cạnh khối “Ảnh màn hình”. Nội dung giải thích tại sao Proxmox không có API chụp màn hình.

GHI CHÚ · MỘT CHI TIẾT KỸ THUẬT NHỎ NHƯNG TỪNG LÀM HỎNG CẢ TÍNH NĂNG

Chú thích ngắn được gắn vào <body> và định vị position:fixed, không dùng ::after của chính nút. Lý do: chấm ? hay nằm trong thẻ có overflow:hidden (thẻ máy, ô bảng), vẽ bên trong sẽ bị cắt cụt. Sự kiện cũng uỷ quyền ở cấp document vì các chấm được sinh lại mỗi lần vẽ khung nhìn.

Chương 7 — Trang Droplets — bảng trung tâm

7.1 Mười ba cột, không phải tám

Hình 7.1. Đủ 13 cột của bảng Droplets ngày 19/09/2026, đánh số theo đúng thứ tự trái sang phải. Cột USB (số 11) thêm ngày 17/09.

Số	Cột	Nội dung và quy tắc hiển thị
①	Dự án	Nhãn màu của dự án. Bảng mặc định xếp theo cột này vì người dùng nghĩ theo dự án trước. Máy chưa thuộc dự án nào hiện “chưa xếp” và xuống cuối (khoá xếp trả \uffff chứ không trả chuỗi rỗng — chuỗi rỗng sẽ nhảy lên đầu). Nhãn là một liên kết: bấm vào nhãn = lọc theo dự án; bấm chỗ khác trong hàng = mở máy.
②	Tên	Tên máy + biểu tượng hệ điều hành (SVG vẽ sẵn, không tải từ CDN) + mã #vmid + huy hiệu LXC nếu là container. Ô có min-width:160px để tên không bị bẻ thành 5 dòng.
③	Trạng thái	Chấm màu + chữ: Đang chạy (xanh) / Đã tắt (xám) / lỗi (đỏ). Từ 15/09 có thêm Đang tạm dừng (vàng) — với Proxmox máy đó là stopped, nhưng vẽ Đã tắt là nói dối vì phiên làm việc còn nguyên.
④	Node	pve-wp2-01 hoặc pve-wp2-02 — máy chủ vật lý đang thực thi.
⑤	Địa chỉ IP	IPv4 lấy qua QEMU Guest Agent, chọn theo MAC của net0. Máy tắt hoặc không có agent ⇒ hiện “— (máy đang tắt)”. Trống là đúng, không phải lỗi.
⑥	vCPU	Số nhân đã cấp cho máy.
⑦	RAM	Dung lượng RAM đã cấp.
⑧	Ổ đĩa	Dung lượng ổ đĩa đã cấp.
⑨	Loại ổ	Chip SSD NVMe / SSD SATA / HDD, tra từ biến B43_STORAGE_MEDIA. Không nhận ra kho ⇒ —. Cả ba chip được ép rộng đúng 104 px để không so le.
⑩	vGPU	Chip hai dòng: trên là card vật lý, dưới là phần máy này được chia (1 GB vGPU, 6 GB Passthrough). Máy không gắn card ⇒ ô trống hẳn, không hiện dấu gạch. Khoá sắp xếp là -(vram_mb) nên máy có card luôn nổi lên trên.
⑪	USB	Một biểu tượng phích cắm nếu máy được gán cổng USB, trống nếu không. Cố ý chỉ có biểu tượng vì bảng đã chật; rê chuột xem cổng, thiết bị đang cắm và khe. Bấm biểu tượng là sang Cấu hình máy chủ → Cổng USB, cuộn đúng tới cổng đó (mục 14.3).
⑫	Uptime	Thời gian phiên làm việc của máy. Máy từng Tạm dừng thì số này cộng dồn cả phần trước lần tạm dừng (Proxmox đếm lại từ 0 mỗi lần bật) và có thêm dấu tạm dừng nhỏ cạnh số; rê chuột thấy tiến trình thật mới chạy bao lâu.
⑬	(không tên)	Nút nguồn: Tắt ▾ khi máy chạy, Bật (hoặc Chạy tiếp với máy đang tạm dừng) khi máy tắt. Bấm nút này không mở trang chi tiết — e.stopPropagation() chặn sự kiện nổi lên hàng. Bấm nút mà bị nhảy trang là lỗi thật. Xem mục 7.5.

Mọi tiêu đề cột có lớp sortable đều bấm được để xếp lại. Khi hai hàng hoà nhau, hệ thống luôn lấy tên máy làm tiêu chí phụ, để thứ tự không nhảy loạn giữa hai lần vẽ.

7.2 Đọc từng ô trong một hàng

Số	Ô	Đang hiện gì và nghĩa là gì
①	Nhãn dự án	CMEV-SERVER màu xanh dương. Màu chọn ở trang Dự án, lưu trong /data/project_meta.json — không lưu trên Proxmox.
②	Chip IP	172.16.20.50 — địa chỉ thật, đọc qua Guest Agent.
③	Chip Loại ổ	SSD — máy này nằm trên kho vmstore.
④	Chip vGPU xanh lá	GTX 1660 Ti / 1 GB vGPU — nvidia-smi chạy được bên trong máy khách, driver 553.74, đã cấp phép.
⑤	Chip vGPU xám	Máy #100 đang tắt ⇒ chưa hỏi được. Đây là kết luận cuối cùng và đúng, không phải trạng thái chờ.
⑥	Nút Tắt (đỏ)	Máy đang chạy. Ảnh ngày 07/09 còn là nút một chiều; từ 15/09 nút ghi Tắt ▾ và mở menu chọn kiểu tắt — mục 7.5.
⑦	Nút Bật (xanh)	Máy đang tắt. Bấm là chạy ngay, không hỏi.

7.3 Chip vGPU — phần dễ hiểu sai nhất của cả trang

Hình 7.3. Năm màu của chip vGPU và việc phải làm với từng màu.

NGUY HIỂM · BỐN GÓC KHUẤT PHẢI NHỚ

▸ Không được kết luận màu chip từ file cấu hình. hostpci0 chỉ nói thiết bị đã được đưa vào máy, không nói hệ điều hành bên trong đã dùng được nó chưa.

▸ Chip xám lúc mới vào trang là ĐÚNG. Bảng vẽ ngay với checking, luồng nền đi hỏi, giao diện tự lấy lại sau 9 giây. Chờ đủ ≥ 12 giây rồi mới đọc màu.

▸ Chờ đủ rồi VẪN xám cũng có thể đúng. Máy khai agent: 1 nhưng chưa cài dịch vụ bên trong thì câu hỏi không bao giờ có lời đáp. Đọc trường vgpu.reason trước khi gọi đó là lỗi.

▸ Intel GVT-g KHÔNG được tô cam. nvidia-smi sẽ không bao giờ tồn tại ở đó. Tô cam nó là bảo người dùng đi cài một thứ không tồn tại ⇒ phải xanh dương.

7.4 Bản mẫu bị lọc khỏi bảng này — cố ý

LƯU Ý · BẢNG CHỈ HIỆN 2 MÁY, NHƯNG HỆ THỐNG CÓ 3

/api/droplets vẫn trả về bản mẫu #102 template01-win10-gpu kèm cờ template: 1; việc lọc nằm ở phía trình duyệt, vì trình tạo máy và bộ chọn node vẫn cần danh sách đầy đủ. Gọi API thấy có bản mẫu mà bảng không hiện ⇒ đúng thiết kế.

▸ Vì sao phải lọc: Proxmox không coi bản mẫu là một tệp ảnh riêng — nó vẫn là một máy ảo, chỉ thêm template: 1 và đổi tên ổ thành base-<vmid>-disk-N (chỉ đọc). Trước đây bảng vẽ nó y hệt một máy đang tắt: không nhãn, có nút Bật (vô nghĩa — Proxmox từ chối khởi động bản mẫu) và có nút Xoá chạy thật.

▸ Bản mẫu win10-wp2-gpu đã bị xoá nhầm hai lần trong ngày 29/08/2026, mỗi lần phải khôi phục từ một bản dump 11 GB.

▸ Điều KHÔNG bảo vệ được ở đây: chỉ máy tạo bằng nhân bản liên kết mới khiến Proxmox từ chối xoá bản mẫu gốc (“base volume in use”). Máy tạo mới bằng qm create thì không níu gì cả.

7.5 Nút bật / tắt — hai chiều CỐ Ý không đối xứng

Từ → đến	Hành vi đúng (từ 15/09/2026)	Nếu thấy khác
stopped → Bật	Chạy ngay, KHÔNG hỏi xác nhận. Máy đang tạm dừng thì nút ghi Chạy tiếp và quay về đúng phiên cũ	Bấm Bật mà hiện hộp xác nhận ⇒ sai
running → Tắt ▾	Mở menu bốn kiểu tắt, mỗi dòng ghi sẵn hậu quả. Ba kiểu chạy ngay; chỉ Cắt điện hiện thêm hộp xác nhận in tên máy	Chọn Cắt điện mà máy tắt luôn không hỏi ⇒ sai và nguy hiểm

Hình 7.4. Menu Tắt ▾ của máy vpn-pc-01. Ảnh chụp khi mọi lệnh ghi đã bị chặn trong trình duyệt, nên không máy nào bị tắt thật.

Số	Thành phần	Giải thích
①	Nút Tắt ▾	Bấm lần nữa, bấm ra ngoài hoặc phím Esc là đóng menu. Menu tự lật lên trên khi sát mép dưới màn hình.
②	Dòng đầu	“Tắt vpn-pc-01 theo kiểu nào?” — tên máy in đậm ngay trong câu hỏi.
③	Tạm dừng	“Giữ nguyên phiên làm việc rồi tắt. Bật lại là quay đúng vào chỗ đang dở.” Máy chưa bật Tạm dừng thì dòng này xám kèm chỉ đường “vào tab Cài đặt của máy để bật” — xám chứ không ẩn, để người dùng biết tính năng có và bật ở đâu. Container LXC không có dòng này.
④	Tắt máy (ACPI)	“Như bấm nút nguồn trên thùng máy.” Hệ điều hành tự đóng chương trình rồi tắt.
⑤	Khởi động lại	Tắt bằng ACPI rồi bật lên lại ngay.
⑥	Cắt điện (chữ đỏ)	“Ngắt nguồn tức thì, như rút phích. Dữ liệu chưa kịp ghi sẽ mất.” Kiểu duy nhất đi qua hộp xác nhận thứ hai.

Hình 7.5. Hộp xác nhận (ảnh 07/09/2026). Ngày nay hộp này chỉ còn hiện cho kiểu Cắt điện, với tiêu đề “Cắt điện máy ảo?”.

Lý do bất đối xứng rất đơn giản: bật máy là việc vô hại, còn tắt máy cắt ngang mọi thứ đang chạy bên trong. Nhưng ba kiểu tắt đầu đã tự mô tả hậu quả ngay trên dòng vừa bấm — hỏi lại lần nữa chỉ là thủ tục, và thủ tục thừa thì người ta bấm qua theo phản xạ. Riêng Cắt điện là thứ duy nhất làm hỏng dữ liệu, nên giữ một bước chặn thật.

7.6 Ghim phiên bản phần cứng ảo +pveN — B43 tự gỡ, và phải nói ra

Bản mẫu mang từ máy chủ khác về thường ghim sẵn machine: pc-q35-11.0+pve2. Máy chủ nào cài gói qemu-server cũ hơn sẽ từ chối bật chứ không tự hạ xuống mức nó chạy được:

Installed qemu-server (max feature level for 11.0 is pve0) is too old

to run machine type 'pc-q35-11.0+pve2', please upgrade node 'pve-wp2-02'

Hành vi đúng khi bấm Bật trong tình huống này: máy lên được, kèm một thông báo màu xanh nhạt (12 giây) nói rõ đã hạ ghim từ mức nào xuống mức nào.

Điều dễ hiểu sai	Sự thật
“Bắt lỗi quanh lời gọi start là đủ”	POST .../status/start chỉ xếp hàng một tác vụ rồi trả UPID + HTTP 200 ngay. Lỗi ghim rơi vào exitstatus của tác vụ, không vào lời gọi. Phải chờ tác vụ xong rồi mới đọc kết quả.
“Cứ gỡ ghim sẵn lúc nhân bản cho chắc”	Proxmox không có API nào công bố mức +pveN tối đa — bảng đó nằm trong mã Perl của gói qemu-server. Dò trước là đoán mò, và sẽ hạ cấp oan những máy chủ vốn chạy được. B43 làm theo lối phản ứng: cứ bật, trúng đúng câu lỗi này mới gỡ.
“Gỡ ghim là mất tính năng”	Với 11.0: +pve1 = tắt host_tunnel cho card VirtIO; +pve2 = bật hv_emcs cho Windows 11/2022/2025. Máy dùng e1000 + Windows 10 thì không dính cái nào.
Bấm Bật hai lần	Trả 200 kèm ghi chú “Máy ảo vốn đã chạy sẵn” — không phải lỗi đỏ.

Chương 8 — Trình tạo Droplet — 7 bước, 5 nhánh

Trang #/create là nơi dễ hiểu sai nhất của cả ứng dụng, vì cùng một nút bấm cho ra năm kiểu máy hoàn toàn khác nhau, tuỳ theo tab bạn đang chọn ở Bước 2.

Hình 8.1. Năm nhánh của nút Tạo Droplet. Chọn nhầm tab rồi kiểm bằng tiêu chí của nhánh khác là kết luận sai.

8.1 Bước 1 — Chọn node, và Bước 2 — Chọn ảnh cài đặt

Hình 8.2. Bước 1 và Bước 2 với đầy đủ 5 tab nguồn ảnh. Bảng Tóm tắt bên phải cập nhật theo thời gian thực.

Số	Mã HTML	Thành phần	Giải thích
①	#gNode	Lưới chọn node	Mỗi thẻ ghi số luồng thật và tổng RAM thật của máy chủ đó.
②	.option-card.disabled	Node đang tắt	pve-wp2-01 bị làm mờ, gắn nhãn offline và khoá bấm. Nếu cho chọn, mọi lời gọi sau đó sẽ treo cho tới khi hết giờ chờ.
③	.option-card.selected	Node đang chọn	pve-wp2-02 — 48 nhân, 94 GB RAM, trực tuyến.
④	Tab 1	Hệ điều hành	7 ảnh đám mây: Ubuntu 24.04/22.04 LTS, Debian 12/13, Rocky Linux 9, AlmaLinux 9, Fedora 41. Mỗi thẻ ghi tối thiểu 10 GB · cloud-init.
⑤	Tab 2	Bản mẫu (số đếm: 1)	Các máy ảo đã được “đúc” thành khuôn trên node đang chọn.
⑥	Tab 3	Đĩa ISO	Máy trống + đĩa cài, tự cài bằng bàn phím ảo.
⑦	Tab 4	Ứng dụng TurnKey (số đếm: 138)	Kho mẫu container LXC lấy từ /nodes/{node}/aplinfo.
⑧	Tab 5	Marketplace (số đếm: 13)	Bấm vào là chuyển sang trang Marketplace — nhánh này không tạo máy.
⑨	#imgPane .os-card	Lưới ảnh hệ điều hành	Biểu tượng vẽ bằng SVG nội tuyến, không tải từ CDN (nhiều máy trong LAN không ra được Internet, logo tải từ ngoài sẽ hiện ô vỡ đúng lúc cần nhìn nhất).

GHI CHÚ · BẢNG TÓM TẮT BÊN PHẢI — THÀNH PHẦN HAY BỊ BỎ QUÊN NHẤT

Cột phải luôn hiện một thẻ Tóm tắt gồm 9 dòng: Node · Ảnh cài đặt · vCPU · RAM · Ổ đĩa · Nơi lưu · Ứng dụng · vGPU · Tên — cập nhật ngay theo từng lựa chọn, kèm nút Tạo Droplet ở dưới. Đây là chỗ cuối cùng nên nhìn trước khi bấm, vì nó gom toàn bộ bảy bước vào một khung nhìn.

Bốn tab nguồn ảnh còn lại

Hình 8.3. Tab Bản mẫu — nhân bản LIÊN KẾT theo mặc định, gần như tức thì và tốn 0 GB lúc đầu.

Hình 8.4. Tab Đĩa ISO — liệt kê các tệp .iso trên kho local của node. Kho local là kho RIÊNG của từng node.

Hình 8.5. Tab Ứng dụng TurnKey — 138 mẫu container dựng sẵn. Chọn ở đây là ra CONTAINER LXC, không phải máy ảo.

Hình 8.6. Tab Marketplace trong trình tạo — bấm vào sẽ chuyển sang trang Marketplace.

Tab	Endpoint được gọi	Kết quả và ràng buộc
Hệ điều hành	POST /api/droplets/from-image	Tải ảnh đám mây về node (bỏ qua nếu đã có) → qm importdisk → gắn cloud-init. Bật lên là dùng được ngay. Ảnh tải về /var/lib/vz/template/iso trên node, không phải trong container B43.
Bản mẫu	POST /api/droplets/clone	Nhân bản liên kết theo mặc định (full = False). Hệ quả có lợi: Proxmox từ chối xoá bản mẫu gốc khi còn máy con (“base volume in use”) — lớp bảo vệ này nằm trong Proxmox, không phụ thuộc giao diện.
Đĩa ISO	POST /api/droplets	Máy trống + ISO gắn sẵn để tự cài.
Ứng dụng TurnKey	POST /api/lxc	Dựng thẳng container. LXC không có cloud-init ⇒ phải đặt mật khẩu hoặc khoá SSH lúc tạo, không thì dựng xong không đăng nhập được.
Marketplace	(chuyển trang)	Không tạo máy. Chỉ sinh lệnh docker run.

LƯU Ý · HAI CHI TIẾT AN TOÀN TRONG NHÁNH TẢI ẢNH ĐÁM MÂY

▸ Tải vào tệp .part rồi mới đổi tên. Đứt mạng giữa chừng thì lần sau tải lại từ đầu, chứ không nhận nhầm một tệp cụt là “đã có”.

▸ image_id chỉ nhận giá trị có trong danh mục OS_CATALOG, không nhận URL tuỳ ý. Nhận URL tuỳ ý thì đây trở thành công cụ bắt máy chủ tải bất cứ thứ gì từ Internet.

8.2 Bước 3 — Cấu hình vCPU và RAM

Hình 8.7. Bảy gói dựng sẵn. Tên và thông số là giá trị THẬT trên hệ thống.

Gói	vCPU	RAM	Ổ đĩa gợi ý
Cơ bản	1	1 GB	10 GB
Nhỏ	2	2 GB	20 GB
Vừa	2	4 GB	30 GB
Lớn	4	8 GB	30 GB
Rất lớn	8	16 GB	40 GB
Chrome ×20	12	24 GB	40 GB
Tuỳ chỉnh	tự đặt	tự đặt	—

Hình 8.8. Bấm thẻ Tuỳ chỉnh sẽ mở hai thanh trượt cùng thước đo tải máy chủ bên dưới.

Số	Mã HTML	Thành phần	Giải thích
①	#rCores	Thanh trượt số nhân vCPU	Trần = maxcpu thật của node (48 với pve-wp2-02), không phải maxcpu × 3. Trần cũ cho phép kéo tới 24 trên máy 8 luồng, khiến người dùng tưởng máy chủ có 24 luồng.
②	#rMem	Thanh trượt RAM	Từ 1 GB tới 92 GB — chừa lại phần cho chính hypervisor.
③	#cpuMeter	Thước đo tải máy chủ	Đọc là: 10/48 — tổng vCPU đã cấp trên node này, gồm phần đang chạy (8) và phần máy mới (2). Thanh chuyển màu cảnh báo khi vượt ngưỡng.
④	.cpu-meter-note	Dòng kết luận	“Còn dư 38 luồng chưa cấp phát trên máy chủ.”

MẸO · VÌ SAO TRẦN MỘT MÁY LÀ MAXCPU MÀ THƯỚC ĐO LẠI CHO PHÉP VƯỢT TỔNG

Cấp vượt (overcommit) vẫn hợp lệ về mặt kỹ thuật, nhưng chỗ để nói điều đó là thước đo tổng, không phải trần của một máy: một máy không tự vượt được số luồng vật lý, nhưng tổng của mọi máy thì có — và thước đo báo đỏ đúng vào lúc đó.

▸ Gói dựng sẵn vượt trần cũng bị khoá kèm lý do. Chỉ chặn thanh trượt là chưa đủ: hai chỗ trong cùng một bước sẽ nói hai con số khác nhau.

▸ Đang chọn gói lớn rồi đổi sang node nhỏ hơn ⇒ hệ thống tự lùi về gói lớn nhất còn vừa kèm thông báo, thay vì giữ nguyên con số không tạo được rồi chỉ báo lỗi lúc bấm Tạo.

8.3 Bước 4 — Ổ đĩa

Hình 8.9. Lưới chọn kho lưu trữ. Mỗi thẻ ghi loại ổ vật lý và dung lượng trống THẬT.

Số	Thành phần	Giải thích
①	#gDisk — lưới kho lưu trữ	Hai lựa chọn thật trên pve-wp2-02: vmstore (SSD SATA — nhanh, còn trống 393 GB) và local-lvm (SSD NVMe — nhanh nhất, còn trống 137 GB). Con số “còn trống” là số đọc trực tiếp, không phải ước lượng.
②	#rDisk — thanh trượt dung lượng	Tự giới hạn theo chỗ trống thật của kho đã chọn. Đổi kho thì trần đổi theo.

NGUY HIỂM · QUY TẮC VÀNG: CHỈ NỚI RỘNG ĐƯỢC, KHÔNG THU NHỎ

Sau khi tạo, ổ đĩa ảo chỉ có thể mở rộng. Thanh trượt ở tab Cài đặt bị khoá cứng ở mức hiện tại. Lý do không phải là Proxmox không làm được, mà là: thu nhỏ đòi thu hệ thống tệp bên trong máy khách trước, và làm sai thứ tự đó là mất sạch dữ liệu. Không có cách nào để giao diện bảo đảm bước bên trong đã làm đúng.

8.4 Bước 5 — Card đồ hoạ vGPU

Hình 8.10. Ô chọn vGPU cùng dòng chú thích dài bên dưới — dòng chú thích này chính là phần đáng đọc nhất của cả bước.

Số	Mã HTML	Giải thích
①	#fVgpu	Ô chọn hồ sơ vGPU. Mỗi dòng mở đầu bằng tên card rút gọn rồi mới tới thông số, ví dụ: GTX 1660 Ti · 1 GB mỗi máy (còn 5 chỗ, 1 đang dùng) · 1920×1080 · 60 fps. Cụm “mỗi máy” bắt buộc phải có — bỏ đi thì GTX 1660 Ti · 1 GB bị đọc thành “card có 1 GB”.
②	#vgpuNote	Dòng chú thích, giải thích trọn vẹn tình trạng card: cách chia đã chốt, còn mấy chỗ, những máy nào đang giữ card, và vì sao các cỡ khác tạm thời không chọn được.

Ha tang da chot 1 GB May tram do hoa (nvidia-256 . GRID RTX6000-1Q), chia 6 phan.

Card dang chia o muc 1 GB moi may - 1 cho da dung, con 5 cho.

Dang giu: #100 may-goc-gpu-gpm, #102 template01-win10-gpu, #103 vpn-pc-01.

Moi vGPU tren cung mot card bat buoc cung co, nen cac muc khac tam thoi khong chon duoc.

Muon doi co thi phai tat het may dang dung card nay truoc.

Card NVIDIA GeForce GTX 1660 Ti . 6 GB VRAM - driver nhin thay no nhu Quadro RTX 6000

(nho vgpu_unlock) tren may chu pve-wp2-02.

So cho da tinh theo VRAM that, khong phai con so driver bao.

LƯU Ý · VÌ SAO Ô CHỌN CHỈ CÒN 3 DÒNG DÙ DRIVER LIỆT KÊ 18 HỒ SƠ

Hai lần lọc (bỏ hồ sơ lớn hơn card, bỏ hồ sơ trái cỡ) rút 18 xuống 3. Ngoài ra hạ tầng còn có thể chốt một cỡ ở trang Cấu hình máy chủ, khiến trang Tạo chỉ chào đúng cỡ đó.

▸ Chốt 1 GB thì ô chọn còn 3 dòng, không phải 1 — 1A/1B/1Q cùng 1 GB nhưng khác dòng sản phẩm. NVIDIA khoá theo cỡ, chặn hai dòng kia là chặn oan. Hồ sơ được chốt đứng đầu danh sách.

▸ Chốt KHÔNG ghi gì lên máy chủ. Nó chỉ ghi nhớ trong /data/vgpu_choice.json. Ghi file trên node là việc của nút Áp dụng cấu hình.

▸ Máy đang gắn vGPU lệch cỡ đã chốt vẫn giữ nguyên hồ sơ của nó trong ô chọn ở tab Cài đặt. Lọc mất nó thì ô nhảy sang giá trị khác, và người dùng bấm Lưu vì việc khác sẽ đổi ngầm card của một máy đang chạy.

8.5 Bước 6 — Xác thực, và Bước 7 — Đặt tên

Hình 8.11. Bước 6. Với máy ảo, đây là nơi chọn khoá SSH sẽ được nhúng vào lúc khởi động đầu tiên.

Số	Mã HTML	Thành phần	Giải thích
①	#fKey	Ô chọn khoá SSH	Danh sách khoá công khai đã lưu ở trang SSH Keys. Khoá được nhúng vào ~/.ssh/authorized_keys của máy ảo ngay lúc boot đầu tiên, qua cloud-init.
—	#ctPassGroup / #fCtPass	Mật khẩu container	Chỉ hiện khi đang tạo container LXC. LXC không có cloud-init, nên phải đặt mật khẩu hoặc khoá SSH ngay lúc tạo, nếu không dựng xong sẽ không đăng nhập được.
②	#fName	Tên Droplet	Tên gợi nhớ, cũng dùng làm hostname.
③	#fProject	Gán dự án	Chọn từ danh sách dự án hiện có, kèm số máy của từng dự án. Chọn “— chưa xếp vào dự án nào —” thì máy sẽ nằm ở nhóm cuối bảng.
④	#fStart	Tự bật cùng máy chủ	Cờ onboot. Bảo đảm dịch vụ tự phục hồi sau khi máy chủ vật lý mất điện rồi bật lại.
⑤	#summary	Bảng Tóm tắt	Chín dòng gom toàn bộ lựa chọn của bảy bước. Nhìn bảng này trước khi bấm là cách rẻ nhất để không tạo nhầm.
⑥	#btnCreate	Nút Tạo Droplet	Bấm là kích hoạt chuỗi tác vụ nền ở phía máy chủ. Đóng trang giữa chừng cũng không sao — việc vẫn chạy tiếp.

Chương 9 — Trang chi tiết — tab Tổng quan

Bấm vào một hàng bất kỳ trong bảng Droplets sẽ mở #/droplet/{node}/{vmid}. Đây là màn hình dày đặc thông tin nhất của cả ứng dụng.

GHI CHÚ · CONTAINER LXC CHỈ CÓ 2 TAB, KHÔNG PHẢI 4

Máy ảo QEMU có bốn tab: Tổng quan · Console · Snapshot · Cài đặt. Container LXC chỉ có Tổng quan và Console — hai tab kia bị ẩn có chủ ý, vì LXC đi nhánh API /lxc hoàn toàn khác /qemu; bấm vào sẽ nhận Configuration file does not exist, nghe y như máy đã bị xoá.

9.1 Thanh tiêu đề — tên, trạng thái, hai chip IP, năm nút nguồn

Hình 9.1. Thanh tiêu đề của Droplet #103 ngày 19/09/2026 và hàng sáu ô số liệu ngay bên dưới. Nút Bật mờ vì máy đang chạy.

Số	Mã HTML	Thành phần	Giải thích
①	#dropletNameEdit	Tên máy, sửa tại chỗ	Bấm vào tên là sửa được ngay, bấm Enter là lưu — không phải mở một hộp thoại riêng.
②	#dPill + huy hiệu node + #vmid	Trạng thái	Nhãn Đang chạy / Đã tắt / Đang tạm dừng, tên node, và mã máy #103.
③	#ipChips	Hai chip IP	LAN và Public — xem ngay dưới bảng này.
④	.pa — Bật	Nút nguồn	Mờ khi máy đang chạy. Với máy đang tạm dừng, chữ đổi thành Chạy tiếp.
⑤	.pa — Tạm dừng	Nút nguồn (mới 15/09/2026)	Đổ trạng thái đang chạy ra đĩa rồi tắt. Chỉ bấm được khi máy đã bật tính năng này ở tab Cài đặt (mục 10.3, Khối 7) — mặc định tắt ở mọi máy. Container LXC không có.
⑥	.pa — Tắt máy (ACPI)	Nút nguồn	Như bấm nút nguồn trên thùng máy.
⑦	.pa — Khởi động lại	Nút nguồn	Tắt bằng ACPI rồi bật lại.
⑧	.pa — Cắt điện	Nút nguồn	Như rút phích — chỉ dùng khi máy treo cứng.
⑨	#tabs	Thanh tab	Tổng quan · Console · Snapshot · Cài đặt.
⑩	.metric-grid	Sáu ô số liệu	Xem mục 9.2.

ĐÚNG THIẾT KẾ · NĂM NÚT Ở ĐÂY KHÔNG HỎI XÁC NHẬN — ĐÚNG THIẾT KẾ

Khác nút Tắt ▾ trong bảng danh sách (mục 7.5): đây là trang chi tiết, người dùng đã chủ đích vào tận nơi, và mỗi nút là một hành động riêng có tên rõ ràng. Đừng báo lỗi vì “thiếu xác nhận”.

Hai chip địa chỉ IP — LAN và Public

Cạnh tên máy có hai chip bấm để chép: LAN 172.16.20.50 và PUBLIC 149.50.211.69 SIN. Cả hai lấy qua QEMU Guest Agent, không cần cài thêm phần mềm giám sát nào bên trong máy.

Giá trị	Cách lấy	Chi phí
IPv4 mạng LAN	agent/network-get-interfaces	gần như tức thì
IPv4 công cộng	agent/exec chạy curl bên trong máy khách	khoảng 0,8 giây, nhớ tạm 5 phút

LƯU Ý · BA CHI TIẾT DỄ HIỂU SAI Ở HAI CHIP NÀY

▸ Địa chỉ LAN là địa chỉ của card net0, chọn theo MAC. Máy có nhiều card ảo (Docker, VPN) thì việc “lấy địa chỉ thuộc dải nội bộ” là chưa đủ để phân biệt — phải so đúng địa chỉ MAC ghi trong file cấu hình.

▸ Chip Public kèm cờ quốc gia là ẢNH, không phải ký tự emoji. Windows không có phông chữ cờ, để emoji thì máy Windows chỉ thấy hai chữ cái.

▸ Con số trong ngoặc [00:00] là BỘ ĐẾM, không phải mốc đồng hồ — nó đếm thời gian kể từ lần địa chỉ công cộng đổi gần nhất.

9.2 Sáu ô số liệu — không phải bốn

Ô	Mã HTML	Đang hiện	Ý nghĩa và bẫy
CPU	#mCpuVal	5 % · 8 nhân	Tỷ lệ chiếm dụng vCPU hiện thời.
Bộ nhớ	#mMemVal	8 % · 1.4 GB / 16 GB	Bẫy lớn. Không có driver bong bóng virtio-balloon trong máy khách thì mem mà Proxmox trả về là bộ nhớ tiến trình QEMU chiếm ở máy chủ — gần như luôn bằng đúng số RAM đã cấp, nên ô đứng ở 100 % dù bên trong máy còn rỗng rãi. Nhận biết: thiếu trường freemem trong status/current. Muốn có số thật phải cài bộ virtio-win.
Ổ đĩa	#mDiskVal	65 % · 21 GB / 32 GB trong máy khách	Hỏi agent/get-fsinfo, bỏ hệ tập tin ảo rồi cộng lại. Không có agent ⇒ “—” kèm lý do. Kết quả nhớ tạm 30 giây (có agent) / 120 giây (không có agent).
Mạng	#mNetVal	1.8 Kbps · ↓ 1.7 Kbps · ↑ 67 bps	Hai bẫy. (a) netin/netout trong status/current là bộ đếm dồn, phải trừ hai lần đọc mới ra tốc độ; nhưng trong RRD chúng đã là byte/giây, trừ nữa là ra rác. (b) Vì phải trừ hai lần đọc, ô này không có số ở nhịp đầu tiên — nó hiện “đang đo…” chứ không hiện 0, vì 0 nhìn y hệt “mạng đứng im”.
GPU	#mGpuVal	0 % · 130 / 1024 MiB khung đệm	Số này Proxmox không có. Nó đến từ kho SQLite riêng của B43.
Uptime	#mUpVal	2 giờ 14 phút · Đang chạy	Thời gian chạy liên tục.

MẸO · THANH CỦA Ô MẠNG THEO THANG LOGARIT, CỐ Ý

Lưu lượng trải qua sáu bậc độ lớn. Neo tuyến tính vào 1 Gbps thì 8 Kbps ra 0,0008 % — thanh trông rỗng y như lúc mạng chết. Nay: 1 Kbps ≈ 0 %, 1 Mbps = 50 %, 1 Gbps = 100 %; dưới 1 Kbps mà khác 0 thì vẫn vẽ 2 % để “có nhúc nhích” thấy được.

Trang tự làm mới 5 giây một lần — nhưng KHÔNG vẽ lại cả trang

Trang chi tiết vá tại chỗ mỗi 5 giây: nhãn trạng thái, sáu ô số liệu, và trạng thái mờ/sáng của bốn nút nguồn. Nó không vẽ lại toàn bộ khung nhìn, vì hai lẽ:

Ngoại lệ có chủ ý: khi trạng thái ĐỔI (bật ⇄ tắt) thì vẽ lại cả trang — lúc đó ô ảnh màn hình, tab Console và các nút nguồn đều phải đổi theo; vá từng ô sẽ ra nửa nọ nửa kia.

NGUY HIỂM · ĐÂY LÀ CHỖ ĐÃ TỪNG GÂY HIỂU NHẦM NẶNG NHẤT

Trước 30/08/2026 trang vẽ đúng một lần rồi đứng im: nhãn vẫn “Đang chạy”, Uptime vẫn đếm số cũ, trong khi nút Chụp lại — vốn gọi máy chủ theo thời gian thực — trả về ERROR: VM 100 not running. Hai ô trên cùng một màn hình nói ngược nhau. Gặp cảnh đó thì tin ô nào gọi máy chủ ngay lúc bấm, đừng tin nhãn.

9.3 Khối Biểu đồ theo thời gian — hai nguồn dữ liệu, cố ý không hợp nhất

Hình 9.2. Bốn đồ thị (CPU · Bộ nhớ · Mạng · GPU) gạt được giữa khung 1 giờ và 24 giờ.

Chỉ số	Nguồn	Lý do chọn nguồn đó
CPU · Bộ nhớ · Mạng · Đĩa I/O	RRD của Proxmox	GET /nodes/{n}/qemu/{id}/rrddata?timeframe=day trả sẵn 1440 điểm, bước 60 giây, đúng 24 giờ. Tự xoay vòng, không phình, còn nguyên sau khi B43 khởi động lại.
GPU	SQLite riêng của B43 (/data/metrics.db)	Proxmox không có số này. Đây là lý do duy nhất kho SQLite tồn tại.

Chép CPU / bộ nhớ / mạng vào SQLite chỉ tạo ra một bản sao thứ hai: lệch nhịp với bản gốc, mất khi container bị dựng lại, và phải tự viết mã dọn. Không đổi lại được gì.

Hình 9.3. Khung 24 giờ. Rê chuột lên một đồ thị bất kỳ sẽ hiện MỘT vạch dóng trên CẢ BỐN đồ thị tại cùng một mốc thời gian — nhìn ra ngay “CPU vọt lên đúng lúc mạng vọt lên”.

9.4 Khối Card đồ hoạ

Hình 9.4. Khối Card đồ hoạ của máy #103 — driver đã chạy và đã được cấp phép.

Số	Mã HTML	Thành phần	Giải thích
①	#gdBadge	Chip vGPU	GTX 1660 Ti / 1 GB vGPU, kèm 0000:81:00.0 · nvidia-256. Được vẽ lại sau khi bấm Kiểm tra.
②	#gdNow	Hộp trạng thái	.is-ok xanh / .is-miss cam / .is-na xanh dương / .is-wait xám. Ở đây: “Driver đang chạy trong máy khách — GRID RTX6000-1Q, 553.74, 1024 MiB, Licensed (Expiry: 2026-12-1)”.
③	#gdRun	Cài driver vGPU	Đổi nhãn thành Cài lại driver khi driver đã chạy. Ba dòng thông số ngay trên nút: Driver máy chủ 550.163.02 · Driver sẽ cài 553.74 · Máy cấp phép https://172.16.10.220:20440.
④	#gdCheck	Kiểm tra driver	Hỏi thật và chờ kết quả (khác với bảng danh sách, vốn trả ngay bản đang có).
—	#gdProgress	Nhật ký tiến trình	Hiện log khi đang cài. “Mất 3–8 phút: tải ~350 MB từ máy chủ này, cài, rồi xin giấy phép. Đóng trang giữa chừng cũng không sao — việc vẫn chạy tiếp bên trong máy ảo.”

Loại máy	Khối Card đồ hoạ	Cài driver	Kiểm tra driver
Không gắn card	Ẩn cả khối	–	–
vGPU NVIDIA	Hiện	Có — hiện	Có — hiện
Passthrough NVIDIA	Hiện	Không — ẩn	Có — hiện
Intel GVT-g	Hiện, hộp xanh dương “Không cần cài gì thêm”	Không — ẩn	Không — ẩn

Lý do: kho driver là bộ GRID, chỉ dùng cho vGPU. Passthrough dùng driver thường do người dùng tự tải; Intel GVT-g thì không có gì để cài.

GHI CHÚ · CÂU HAY BỊ HỎI

Máy tạo từ ảnh đám mây KHÔNG tự có driver vGPU. Cloud-init chỉ cài qemu-guest-agent — chính là kênh để nút này gửi lệnh vào. Driver thì luôn phải bấm nút.

9.5 Khối Mạng — tách rõ hai nguồn dữ liệu

Hình 9.5. Khối Mạng của máy #103: một card do máy chủ cấp, và các card do phần mềm bên trong tạo ra.

Phần	Nguồn	Có khi nào
Card ảo (net0, model virtio, cầu nối vmbr0, MAC)	File cấu hình của máy	Luôn có, kể cả khi máy đang tắt
Địa chỉ IP	QEMU Guest Agent	Chỉ khi máy chạy và có agent

Máy tắt hoặc không có agent thì khối này không được để trống trơn — nó phải hiện lý do kèm gợi ý. Trước đây ô này in nguyên chuỗi net0 nên người dùng nhìn địa chỉ MAC mà tưởng là IP.

NGUY HIỂM · FE80::… KHÔNG PHẢI ĐỊA CHỈ IPV6 CỦA MÁY

Mọi card mạng đều tự sinh một địa chỉ link-local như vậy; nó chỉ đi được trong đúng một đoạn mạng, không kết nối tới máy từ nơi khác được. Hiện nó dưới nhãn “IPv6” là nói sai — người dùng sẽ tưởng máy đã có IPv6 rồi đem đi dùng.

▸ B43 phân loại theo chính chuỗi địa chỉ, và cố ý không tin metadata: bỏ qua khoá ip-address-type của agent (agent khai ipv6 cho cả link-local) và bỏ qua tên khoá inet6 của LXC.

▸ Link-local hiện dưới nhãn nhạt riêng LINK-LOCAL kèm câu “Card này chưa có địa chỉ IPv6 dùng được — chỉ có link-local.”

▸ Khối Card khác bên trong máy khách liệt kê riêng những địa chỉ do phần mềm bên trong tạo ra (Docker, VPN, cầu nối ảo) — ở ví dụ này là 172.21.171.207/32 của đường VPN. Gộp chung với net0 là làm người đọc tưởng máy chủ đã cấp địa chỉ đó.

9.6 Khối Ảnh màn hình

Hình 9.6. Khối Ảnh màn hình của một máy đang gắn vGPU: khung đen, kèm lời giải thích đầy đủ và địa chỉ Remote Desktop để vào xem thật.

ĐÚNG THIẾT KẾ · KHUNG ĐEN Ở ĐÂY LÀ ĐÚNG THIẾT KẾ, KHÔNG PHẢI HỎNG

Máy đang dựng hình bằng driver NVIDIA GRID của vGPU, nên màn hình giả lập của QEMU không còn được vẽ nữa — ảnh chụp và Console noVNC đều chỉ ra một khung đen. Trước khi Windows nạp driver (màn hình BIOS, logo khởi động) thì vẫn chụp được bình thường. Muốn nhìn màn hình máy thì vào bằng Remote Desktop.

Về mặt kỹ thuật, khối này là một trong những phần khó nhất của B43:

9.7 Bảng Cấu hình và khối Mô tả

Hình 9.7. Bảng Cấu hình thô đọc thẳng từ file cấu hình của máy, và khối Mô tả sửa được tại chỗ.

Bảng Cấu hình liệt kê hệ điều hành, số nhân, bộ nhớ, chuỗi ổ đĩa (vmstore:vm-103-disk-0,size=32G) và chuỗi vGPU (0000:81:00.0,mdev=nvidia-256). Đây là nguồn sự thật thô — khi giao diện và bảng này nói khác nhau thì bảng này đúng.

LƯU Ý · Ô MÔ TẢ CÓ HAI CHỖ, HAI KHO CHỨA KHÁC NHAU

Mô tả của máy ảo (PUT /api/droplets/{n}/{id}/description) ghi vào trường description của Proxmox. Mô tả của bản sao lưu (GET/PUT /api/backups/notes) ghi vào tệp ghi chú đi kèm bản dump. Hai thứ không liên quan gì tới nhau, và sửa nhầm chỗ thì ghi chú biến mất khỏi nơi bạn định tìm.

Chương 10 — Console, Snapshot và Cài đặt

10.1 Tab Console — noVNC chạy qua chính B43

Hình 10.1. Tab Console. Toàn bộ cảnh báo về vGPU được viết sẵn ngay trên trang, trước khi người dùng kịp bấm.

B43 đứng giữa: trình duyệt chỉ nói chuyện với B43, còn vé Proxmox là vé của B43. Người dùng không phải đăng nhập Proxmox và không gặp cảnh báo chứng chỉ tự ký. Ba đường chuyển tiếp trong app/console_proxy.py:

Đường	Việc
GET /console	Trang noVNC lấy từ gốc Proxmox
GET /novnc/*	JavaScript, CSS, ảnh, âm thanh, gói ngôn ngữ của trang đó
/api2/*	HTTP: trang tự gọi …/vncproxy xin vé · WebSocket: …/vncwebsocket là luồng RFB thật

Hình 10.2. Console đang chạy thật. Trạng thái đo được lúc chụp: “Connected (encrypted) to QEMU (vpn-pc-01)”, khung vẽ 1024×768.

NGUY HIỂM · CONSOLE CHỈ CHẠY TRONG NGỮ CẢNH BẢO MẬT (HTTPS)

Mở B43 bằng http://172.16.10.220:20430 thì noVNC in ra “noVNC requires a secure context (TLS). Expect crashes!” rồi rớt WebSocket ngay sau lời chào RFB với mã 1006. Lý do: phần xác thực VNC cần crypto.subtle, thứ không tồn tại ngoài ngữ cảnh bảo mật.

▸ Đây không phải lỗi của proxy — đã chứng minh: cùng đường đó, một trình khách Python bắt tay xong và nhận đúng b'RFB 003.008\n'.

▸ Vì thế nút Mở console tự nhảy sang B43_PUBLIC_HTTPS_URL khi trang đang là HTTP. Chưa đặt biến đó thì nó từ chối mở kèm lời giải thích, chứ không mở một cửa sổ chắc chắn hỏng.

Bẫy đã dính đủ	Sự thật
Query bị viết lại phía máy chủ	noVNC đọc console, vmid, node bằng location.search của chính nó. Bản đầu viết lại query rồi mới chuyển tiếp: HTML trả về giống hệt, mọi tài nguyên 200, nhưng consoletype là undefined nên noVNC ném "implement me" và chỉ hiện “noVNC encountered an error: undefined”. Nay dùng 307 chuyển hướng để trình duyệt đổi URL thật.
/console có dấu / ở cuối	noVNC dựng địa chỉ WebSocket bằng new URL(path, location.href) với path tương đối. Ở /console, thư mục gốc là / ⇒ ra /api2/json/…. Thành /console/ là ra /console/api2/json/…, không route nào bắt.
Console mở ra ERR_CONNECTION_REFUSED	Proxmox không trả khoá host trong vncproxy (nó mặc định người gọi đang đứng trên chính máy đó). Giao diện đoán theo location.hostname sẽ trỏ về HP1 — nơi không có cổng 8006. Backend nay tự gắn host + port_web vào phản hồi.

10.2 Tab Snapshot

Hình 10.3. Danh sách điểm phục hồi của máy #103. Cột Mô tả giữ nguyên xuống dòng, nên ghi chú nhiều gạch đầu dòng vẫn đọc được.

Cột / nút	Giải thích
Tên	Tên định danh của điểm phục hồi. Ví dụ thật: Org, GPM_LOGIN_VPN, Notebook_OK.
Mô tả	Ghi chú vì sao tạo. Ví dụ thật: “- Mới cài GPM_LOGIN / - Mới cài Kaspersky VPN”. Đây là ô đáng đầu tư nhất — sau vài tháng, cái tên không nói được điều gì.
Thời điểm	Ngày giờ chụp, định dạng Việt Nam.
Khôi phục	Đưa máy quay ngược về đúng trạng thái của điểm đó.
Xoá	Giải phóng lớp dữ liệu vi sai.
#newSnap	Nút Tạo snapshot ở góc trên.

Mã HTML	Ô	Giải thích
#snName	Tên snapshot	Đặt tên viết liền không dấu, dùng gạch ngang.
#snDesc	Mô tả	Ghi rõ mục đích. Đồng nghiệp — và chính bạn sau ba tháng — sẽ cần.
#snState	Lưu cả trạng thái RAM (chậm hơn)	Có tích: Proxmox ghi cả bộ nhớ RAM xuống ổ, cho phép khôi phục lại đúng những cửa sổ ứng dụng đang mở. Không tích: chỉ chụp ổ đĩa, nhanh hơn nhiều, khôi phục ra máy như vừa bị cắt điện.

NGUY HIỂM · SNAPSHOT KHÔNG PHẢI BẢN SAO LƯU

Lớp vi sai của snapshot nằm cùng một ổ đĩa với máy đang chạy. Ổ hỏng là mất cả máy lẫn toàn bộ snapshot. Xem sơ đồ so sánh ở mục 13.1.

10.3 Tab Cài đặt — tám khối

Tab này dài, gồm tám khối riêng biệt (sáu khối trước 17/09/2026, thêm USB Passthrough và Tạm dừng (ngủ)), mỗi khối có nút lưu riêng vì chúng gọi endpoint khác nhau và hỏng vì lý do khác nhau. Gộp chung thì một lỗi nhỏ ở khối này kéo đổ cả bó thay đổi ở khối kia.

Khối 1 — Cấu hình phần cứng

Hình 10.5. Khối Cấu hình phần cứng. Dòng vàng ở đầu khối nói rõ thay đổi có hiệu lực khi nào.

Mã HTML	Thành phần	Giải thích
.st-note	Cảnh báo trạng thái	“Máy đang chạy. Thay đổi sẽ được lưu ngay nhưng chỉ có hiệu lực sau lần tắt rồi bật tới. Tick “tắt máy trước khi lưu” bên dưới nếu muốn áp dụng ngay.”
#stC	Số nhân CPU	Thanh trượt, kèm dòng phụ “Toàn máy chủ: 16/48 vCPU”.
#stM	Bộ nhớ RAM	Thanh trượt, kèm “Tối đa 94 GB — RAM không chia sẻ vượt mức được như vCPU.”
#stD	Dung lượng ổ đĩa	Chỉ nới rộng được, không thu nhỏ. Thanh trượt khoá ở mức hiện tại. Dòng giải thích ngay bên dưới: “Thu nhỏ đòi thu hệ thống tệp bên trong trước — làm sai là mất sạch dữ liệu.”
#stG	Card đồ hoạ ảo (vGPU)	Gán thêm, đổi hồ sơ hoặc gỡ bỏ. Luôn giữ lại hồ sơ máy đang dùng trong danh sách, kể cả khi nó lệch cỡ đã chốt.
#stN	Tên máy	Đổi tên.
#stBoot	Tự bật cùng máy chủ	Cờ onboot.
#stAg	Bật QEMU Guest Agent	Chỉ tạo cổng phía máy chủ. Vẫn phải cài dịch vụ bên trong máy khách (apt install qemu-guest-agent). Bật cờ rồi tưởng xong là hiểu sai.
#stStop	Tắt máy trước khi lưu	Áp dụng thay đổi ngay thay vì chờ lần khởi động sau.
#stSave	Lưu thay đổi	Chỉ lưu khối này.

LƯU Ý · BẪY HOSTPCI0 ĐÃ SỬA — VÀ BÀI HỌC RÚT RA

Ô chọn vGPU gửi lên <pci>,<mdev>, còn Proxmox đòi <pci>,mdev=<type>. Ghép thẳng thì nó trả 400 Parameter verification failed mà không nói sai khoá nào. Đường tạo máy đã đi qua hàm chuẩn hoá từ lâu; riêng đường resize (chính tab này) bị sót ⇒ tạo máy mới có vGPU thì được, còn gán vGPU cho máy đang có thì luôn hỏng.

▸ Tên khoá hỏng nằm trong trường errors, không nằm trong message. message chỉ là câu vô nghĩa “Parameter verification failed.”

▸ Proxmox chỉ kiểm DẠNG, không kiểm tồn tại. mdev=khong-ton-tai-xyz vẫn được nhận HTTP 200 và chỉ vỡ lúc bật máy. Đừng coi “lưu được” là “đúng”.

Khối 2 — Địa chỉ MAC

Hình 10.6. Thẻ Địa chỉ MAC và thẻ Định danh phần cứng. Huy hiệu đỏ “Trùng 1 máy” là cảnh báo, không phải chặn.

Mỗi card netN một hàng: ô nhập, nút Ngẫu nhiên, nút Áp dụng. Ô nhận mọi kiểu gõ — BC:24:11:A1:B2:C3, BC-24-11-A1-B2-C3, bc2411a1b2c3, có cả dấu cách — vì ba nơi người dùng chép MAC (Linux, Windows, Proxmox) viết ba kiểu khác nhau.

Luật	Nội dung	Sinh ra từ kiểu hỏng nào
① CHẶN	Địa chỉ multicast — byte đầu là số lẻ (BD, 01, 33…)	Dùng làm địa chỉ nguồn thì switch lặng lẽ vứt khung đi: máy “có mạng” trên giấy tờ mà không ai trả lời, không một thông báo lỗi nào. Gõ hex ngẫu nhiên là dính 50 %. Nút Ngẫu nhiên dùng tiền tố BC:24:11 của Proxmox nên luôn an toàn.
② CẢNH BÁO	Trùng MAC với máy khác — quét mọi VM và LXC trên mọi node đọc được	Hai máy cùng MAC trên một lớp 2 làm bảng MAC của switch nhảy loạn ⇒ CẢ HAI mất mạng. Cảnh báo chứ không chặn: nhân bản định danh để làm máy dự phòng (mỗi lúc chỉ bật một máy) là việc hợp lệ.
③ GIỮ NGUYÊN	Mọi tuỳ chọn khác trên dòng netN	Ghi đè cả dòng bằng virtio=<MAC>,bridge=vmbr0 là cách nhanh mà sai: nó ném đi tag (VLAN), firewall, mtu, queues, link_down mà không báo một câu.

LƯU Ý · SAU KHI ĐỔI MAC

Máy QEMU đang chạy vẫn giữ MAC cũ — phải tắt rồi bật lại (khởi động lại từ trong hệ điều hành là chưa đủ, QEMU phải dựng lại thiết bị). Container LXC thì nhận ngay.

▸ Bên trong máy, hệ điều hành coi đây là một card mạng khác: Windows tạo hồ sơ mạng mới rồi hỏi lại Public/Private, DHCP cấp lượt thuê mới ⇒ IP nhiều khả năng đổi.

▸ Router ER605 đang ràng buộc IP–MAC, nên máy cần giữ nguyên IP phải sửa cả ràng buộc bên đó.

Khối 3 — Định danh phần cứng (chỉ đọc)

Hình 10.7. SMBIOS UUID và VM Generation ID, kèm cảnh báo trùng. Cả hai bấm vào là chép.

Nhân bản một đĩa cho ra những máy trùng tên Windows, trùng SID, trùng MachineGuid, trùng cả số hiệu ổ C: — đứng bên trong hệ điều hành không tài nào biết mình đang ở máy nào. Hai giá trị này là thứ duy nhất phân biệt chúng.

Khối 4 — Ổ đĩa cài đặt dùng chung

Hình 10.8. Ô tick Ổ đĩa cài đặt và Vùng nguy hiểm ở cuối tab.

Một ảnh ISO (local:iso/lotus-setup.iso, nhãn LOTUS_SETUP, 512 MB) chứa kho bộ cài, gắn vào máy ảo kiểu CD-ROM bằng đúng một ô tick. Bên trong có windows\win10_setup.bat, bộ virtio-win và driver NVIDIA.

MẸO · VÌ SAO LÀ ISO CHỨ KHÔNG PHẢI MỘT Ổ ĐĨA ẢO DÙNG CHUNG

Proxmox không có cờ chỉ-đọc cho ổ đĩa máy ảo (ro chỉ tồn tại cho mountpoint của LXC). Một ổ ghi được mà hai máy cùng gắn sẽ làm hỏng hệ tệp của nhau. CD-ROM thì chỉ đọc theo bản chất, nên bao nhiêu máy gắn cùng lúc cũng an toàn. Thêm nữa, kho local không bật kiểu nội dung images nên ổ đĩa ảo cũng không đặt lên đó được.

▸ QEMU không cắm nóng thiết bị IDE. Máy trước đó chưa có ổ CD thì phải tắt bật lại mới thấy. Đừng suy điều này từ file cấu hình — hỏi GET /nodes/{n}/qemu/{id}/pending: còn khoá pending nghĩa là máy đang chạy chưa nhận.

▸ Muốn thêm tệp vào đĩa thì sửa B43_Lotus_Cloud/setup_disk/content/ trên HP1 rồi chạy build.sh.

Khối 5 — Ổ chung (mạng)

Hai ô tích, mỗi ô một kho dùng chung trên máy chủ file CT 200 sharestore-smb. Tick một ô là B43 làm trọn gói: cắm card mạng vào cầu nội bộ vmbr1, tạo tài khoản Samba riêng cho chính máy này, rồi gắn ổ bên trong máy khách. Không phải chạy lệnh gì trong Windows, cũng không phải đặt địa chỉ IP bằng tay.

Hình 10.9. Thẻ Ổ chung (mạng) trên máy 103, cả hai ổ đã nối và dùng chung card net1.

	Thành phần	Giải thích
①	#ocCard · tiêu đề	Ổ chung (mạng) — tên gọi cố ý: đây là ổ mạng (SMB), không phải ổ đĩa ảo gắn thêm.
②	Huy hiệu card	Trạng thái của card mạng dùng chung: card net1 · 10.77.0.173 khi đã cắm, chưa cắm card khi chưa. Hai ô tích dùng chung đúng một card — nó tự cắm khi tick ô đầu tiên và tự rút khi bỏ tick cả hai.
③	Ô tích F: — Ổ nhanh	Kho \\10.77.0.10\fast — 500 GB CMR, file nhỏ, truy cập ngẫu nhiên (hợp với profile Chrome). Trên Linux là /mnt/o_nhanh. Tick là hành động ngay, không chờ nút Lưu.
④	Huy hiệu hàng F:	Trạng thái của riêng ổ F: — xem bảng trạng thái bên dưới.
⑤	Ô tích S: — Ổ chung	Kho \\10.77.0.10\share — 3 TB, file lớn, ghi tuần tự, kho lưu trữ. Trên Linux là /mnt/o_chung.
⑥	Huy hiệu hàng S:	Như ④, cho ổ S:.
⑦	Ba dòng gợi ý	(a) tick là xong — B43 gắn ổ cho mọi người dùng trong máy, kể cả phiên RDP, và tự nối lại sau khi khởi động; (b) hai ổ dùng chung một card, mỗi máy một tài khoản Samba riêng, bỏ tick cả hai mới thu hồi quyền; (c) vì là ổ mạng nên ảnh chụp máy ảo vẫn dùng bình thường và nhiều máy ghi cùng lúc vẫn an toàn.

Máy chưa tick ô nào thì thẻ trông như hình dưới: huy hiệu card ghi chưa cắm card, hai hàng đều Chưa dùng.

Hình 10.10. Cùng thẻ đó trên máy 100 đang tắt — chưa tick ô nào nên chưa có card.

Huy hiệu ở mỗi hàng đọc trạng thái từ bên trong máy khách (Windows hỏi Get-SmbGlobalMapping, Linux đọc /proc/mounts), chứ không suy ra từ việc B43 đã từng chạy thành công:

Huy hiệu	Nghĩa	Cần làm gì
Đã nối F: / Đã nối S:	Đã kiểm tận trong máy — ổ có thật	Không
Chưa dùng	Chưa tick ô này	Tick nếu muốn dùng
Đang nối… / Đang gỡ trong máy…	Việc đang chạy; thẻ tự hỏi lại mỗi 4 giây	Chờ vài giây
Chờ máy bật / Gỡ khi máy bật	Máy đang tắt nên chưa làm được trong máy; việc đã ghi vào hàng đợi	Bật máy — B43 tự làm nốt
Máy đang tắt	Đã tick nhưng máy chưa chạy	Bật máy
Máy không có guest agent	Không gọi được vào trong máy	Cài qemu-guest-agent trong máy khách (xem Khối 1)
Chưa nối trong máy	Có card nhưng trong máy không thấy ổ	Bấm nút Nối ổ … trong máy
Nối lỗi / Gỡ lỗi	Thất bại; dòng chữ đỏ ngay dưới nói rõ lý do	Đọc dòng đỏ rồi thử lại

MẸO · VÌ SAO KHÔNG PHẢI CHẠY GÌ TRONG WINDOWS

B43 dùng New-SmbGlobalMapping — ánh xạ thuộc về cả máy, không thuộc phiên đăng nhập nào, nên mọi người dùng và mọi phiên RDP đều thấy ổ, và ổ tự nối lại sau khi khởi động. Không để lại script, tác vụ hẹn giờ hay file mật khẩu nào trong máy.

▸ Đừng thay bằng net use qua guest agent. Guest agent chạy dưới quyền SYSTEM, mà ổ mạng thì thuộc từng phiên đăng nhập: lệnh báo thành công, ổ có thật trong phiên của SYSTEM, còn người RDP vào không thấy gì cả.

▸ Máy Linux: B43 cài cifs-utils nếu thiếu và dùng systemd automount, nên máy vẫn khởi động bình thường ngay cả khi máy chủ file đang tắt.

LƯU Ý · BỎ TICK MỘT Ổ KHÔNG THU HỒI TÀI KHOẢN

Cả máy chỉ có một tài khoản Samba vm<vmid>, dùng cho cả hai ổ. Bỏ tick một ổ chỉ gỡ ổ đó; tài khoản, card và ổ còn lại giữ nguyên. Quyền chỉ bị thu hồi khi bỏ tick cả hai.

▸ Máy nhân bản từ một máy đã tick sẽ có sẵn card, nhưng tài khoản Samba thuộc về máy gốc ⇒ thẻ báo Chưa nối trong máy. Bấm Nối ổ … trong máy để cấp tài khoản riêng.

▸ Container LXC không có thẻ này — container gắn thẳng thư mục bằng mpN.

▸ Máy chủ chưa dựng cầu vmbr1 thì thẻ chỉ ghi chưa dựng ổ chung ở đây, không có ô tích.

NGUY HIỂM · MÁY CHỦ PROXMOX TẮT LÀ Ổ BIẾN MẤT KHỎI MỌI MÁY

Máy chủ file nằm ngay trên node (CT 200), không phải NAS rời. Node tắt thì cả F: lẫn S: biến mất trên mọi máy ảo cùng lúc. Đây là đánh đổi đã chấp nhận để lấy tốc độ trong nhà — đừng đặt dữ liệu chỉ có một bản ở đó mà không có bản sao lưu.

Khối 6 — USB Passthrough (chỉ đọc) và Khối 7 — Tạm dừng (ngủ)

Hình 10.11. Hai khối mới trên máy 103: USB Passthrough chưa gán cổng nào; Tạm dừng đang bật, kèm số đo thật trong máy.

Số	Thành phần	Giải thích
①	Tiêu đề USB Passthrough	Khối chỉ đọc. Cổng USB là tài nguyên của máy chủ: gán cho máy này tức là lấy khỏi máy khác, nên chỗ duy nhất được gán là trang Cấu hình máy chủ — nơi nhìn thấy toàn cảnh.
②	Huy hiệu Chưa gán	Hoặc danh sách cổng đang gán cho máy này, kèm thiết bị đang cắm.
③	Dòng nhắc vàng	“Gán một cổng rồi thì mọi thứ cắm vào cái lỗ đó trên máy chủ sẽ chui thẳng vào đây.”
④	Nút Mở Cấu hình máy chủ → Cổng USB	Đi thẳng sang tab gán cổng (mục 14.3).
⑤	Tiêu đề Tạm dừng (ngủ)	Khối có ô tick duy nhất — xem sơ đồ ngay dưới.
⑥	Huy hiệu Đang bật / Đang tắt	Trạng thái của tag b43-tam-dung trong cấu hình máy.
⑦	Ô tick Cho phép Tạm dừng máy này	Mặc định KHÔNG tick ở mọi máy. Tick là hành động ngay, không chờ nút Lưu.
⑧	Dòng cảnh báo cam	Chỉ hiện với máy có card đồ hoạ: Proxmox không đổ RAM ra kho được, phải để chính Windows ngủ đông — và Windows chiếm vĩnh viễn một tệp hiberfil.sys trên ổ C: (khoảng 40 % RAM), kể cả khi cả năm không tạm dừng lần nào. Bỏ tick là B43 xoá tệp đó và trả lại chỗ.
⑨	Dòng số đo	Đo trong máy lúc mở trang: hiberfil.sys 3.2 GB · ổ C: còn 9.4 GB / 31 GB · RAM 8.0 GB.
⑩	Dòng chú thích	Không tick thì dòng Tạm dừng trong menu Tắt ▾ vẫn hiện nhưng xám.

Hình 10.12. Hai đường Tạm dừng. Người dùng không chọn — B43 nhìn phần cứng của máy mà chọn.

NGUY HIỂM · MÁY CÓ CARD ĐỒ HOẠ: KHÔNG TẮT CARD TRƯỚC KHI NGỦ LÀ KHỞI ĐỘNG LẠI BẨN

Đo trên VM 103 ngày 15/09/2026, hai lần chạy chỉ khác đúng một bước. Card còn bật: nhật ký Windows ra sự kiện 41 + 6008 (tắt bẩn), tiến trình đang chạy chết. Tắt card bằng Disable-PnpDevice trước: sự kiện 107 resumed from sleep, tiến trình còn sống, giờ khởi động không đổi. B43 làm việc tắt/bật lại card tự động.

▸ Máy không có card: cần chỗ trống RAM × 2 + 500 MB trên kho chứa trạng thái. B43 luôn tự chọn kho đó — để Proxmox tự chọn đã làm một máy kẹt lock: suspended thật.

▸ Ngủ đông trong Windows còn cần cờ enable-s4=1 của máy ảo: B43 tự ghi cờ rồi báo phải Tắt – Bật một lượt; khởi động lại trong Windows không đủ.

▸ Chi tiết từng bẫy ở Phụ lục H.3.

Khối 8 — Vùng nguy hiểm

NGUY HIỂM · XOÁ DROPLET

“Xoá vĩnh viễn Droplet này cùng toàn bộ ổ đĩa. Không thể hoàn tác.” Nút #delBtn màu đỏ nằm trong một khung viền đỏ tách hẳn khỏi mọi thứ khác, ở tận cuối trang — để không ai bấm phải nó khi đang cuộn tìm thứ khác.

▸ Xoá máy cũng xoá luôn số liệu GPU của máy đó trong /data/metrics.db, vì số hiệu máy ảo được cấp lại ngay sau khi xoá.

▸ Xoá máy không xoá bản sao lưu VZDump của nó — bản sao lưu là tệp độc lập nằm trong kho, phải xoá riêng ở trang Sao lưu.

Chương 11 — Hạ tầng — sức khoẻ máy chủ

11.1 Thẻ node và hai nút nguồn bất đối xứng

Hình 11.1. Node pve-wp2-01 đang tắt. Đây chính là hành vi đã thiết kế: một node chết KHÔNG được làm hỏng cả trang.

Số	Thành phần	Giải thích
①	Thẻ node pve-wp2-01	Tên node là một liên kết mở thẳng giao diện Proxmox gốc (cổng 8006) trong tab mới.
②	Huy hiệu offline	Backend bắt lỗi từng node riêng, trả status: offline kèm error — không ném ngoại lệ ra toàn cục. Tắt một node mà thấy trang trắng ⇒ đó mới là lỗi hồi quy.
③	Nút Send Wake-on-LAN	Chỉ hiện khi node offline và có khai trong B43_NODE_WOL. Bấm là gửi ngay, không hỏi lại — gửi nhầm một gói đánh thức thì chẳng hỏng gì.
④	Dòng hướng dẫn .node-off-note	Giải thích node đang tắt và cách đánh thức. Node chưa khai MAC thì hiện hướng dẫn khai báo, thay vì hiện một nút bấm vô hiệu.

Máy chủ đang chạy thì thẻ trông như hình dưới. Ảnh chụp ngày 07/09/2026 chỉ có bốn ô số liệu; từ giữa tháng 9 thẻ có năm ô, nút Cấu hình, và khối đồ thị ngay bên dưới (mục 11.4).

Hình 11.2. Thẻ máy chủ pve-001 (nhãn hiển thị WP3_PVE1) ngày 19/09/2026: năm ô số liệu, hai huy hiệu nhiệt theo socket.

Số	Thành phần	Đang hiện	Ý nghĩa
①	Nhãn máy chủ	WP3_PVE1 ↗	Nhãn hiển thị đặt trong hộp Cấu hình; bấm là mở giao diện Proxmox gốc (cổng 8006) ở tab mới.
②	Tên thật + địa chỉ	pve-001 · @172.16.30.102	Tên node trong Proxmox và địa chỉ B43 đang gọi tới — dùng để đối chiếu.
③	Nút Cấu hình	—	Sửa nhãn hiển thị, địa chỉ IP và khai báo Wake-on-LAN của máy chủ này — không phải sửa .env.
④	Nút Request Poweroff	đỏ	Tắt nguồn cả máy chủ — luôn hỏi lại (xem bảng dưới).
⑤	Huy hiệu trạng thái	online	Hoặc offline như Hình trên.
⑥	Ô CPU	1%	Tải hiện thời của cả máy chủ.
⑦	Dòng phụ ô CPU	≈ 1.1 / 88 luồng đang chạy	Đổi phần trăm ra số luồng đang bận — 1 % của 88 luồng nghe như không có gì, nhưng là gần trọn một luồng. Chân ô ghi 88 luồng · 2 socket.
⑧	Ô Bộ nhớ	10% · 13 GB / 126 GB	RAM đã dùng trên tổng RAM vật lý.
⑨	Ô Uptime	8 ngày 11 giờ · PVE 9.2.2	Thời gian chạy liên tục; chân ô là phiên bản Proxmox.
⑩	Ô Droplets	4	Số máy ảo QEMU trên node, kể cả bản mẫu — không đếm container LXC. Ngày chụp: #100, #101, #102 (bản mẫu), #103 = 4; hai container #200, #201 không nằm trong số này. Sách bản 13/09 ghi “máy ảo và container” là sai.
⑪	Ô Nhiệt CPU	CPU0 71° · CPU1 72°	Mỗi socket một huy hiệu, màu theo ngưỡng của chính con chip. Bấm để mở bảng nhiệt từng nhân — mục 11.5.

Nút	Hiện khi	Hỏi lại?	Vì sao
Send Wake-on-LAN	node offline và có khai MAC	Không — Không	Gửi nhầm gói đánh thức thì không hỏng gì.
Request Poweroff	node online	Có — Bắt buộc	Kéo theo mọi máy ảo trên node, và bật lại chỉ còn mỗi Wake-on-LAN.

Hình 11.3. Hộp xác nhận trước khi tắt nguồn máy chủ. Ảnh chụp sau khi đã chặn mọi lời gọi mạng.

ĐÚNG THIẾT KẾ · BẤM TẮT XONG NODE VẪN ONLINE VÀI CHỤC GIÂY — ĐÚNG THIẾT KẾ

POST /shutdown cố tình không ngắt mạch ngay. Ngắt ngay thì node báo offline khi máy còn đang tắt dở cả phút; người dùng thấy nút Wake hiện ra, bấm vào lúc máy vẫn đang chạy, gói bay tới nơi mà chẳng có tác dụng, rồi kết luận nhầm là Wake-on-LAN hỏng.

11.2 Đánh thức máy chủ từ xa — gói tin đi qua node còn sống

Hình 11.4. Đường đi thật của gói đánh thức. Khai báo B43_NODE_WOL cho mỗi node một relay_host là node còn lại.

NGUY HIỂM · HỆ QUẢ PHẢI NHỚ: TẮT CẢ HAI NODE LÀ MẤT ĐƯỜNG ĐÁNH THỨC TỪ XA

Hai node lấy nhau làm trạm chuyển tiếp. Tắt cả hai thì không còn máy nào trong đoạn mạng lớp 2 của WP2 để phát gói Magic Packet ra — lúc đó phải đến tận nơi bấm nút nguồn vật lý, hoặc dùng một thiết bị khác trong cùng dải 172.16.20.0/24.

Ba lý do kỹ thuật khiến phải chuyển tiếp thay vì bắn thẳng từ HP1:

11.3 Bảng Kho lưu trữ và bảng bóc tách

Xem mục 4.2 và 4.3 cho phần số liệu và cách đọc. Ở đây chỉ nhắc thao tác: bấm vào một dòng trong bảng Kho lưu trữ sẽ mở bảng bóc tách dung lượng (GET /nodes/{n}/storages/{stg}/content), liệt kê từng mục đang nằm trong kho đó.

11.4 Biểu đồ theo thời gian của máy chủ

Ngay dưới năm ô số liệu là sáu đồ thị luôn hiện, không cần bấm, dùng chung một nút chuyển 1 giờ / 24 giờ và một vạch dóng chung khi rê chuột qua bất kỳ ô nào.

Hình 11.5. Sáu đồ thị của pve-001 lúc 20:31 – 21:30 ngày 19/09/2026.

Số	Đồ thị	Nguồn	Đọc thế nào
①	Nút 1 giờ / 24 giờ	—	Đổi khung thời gian cho cả sáu ô cùng lúc.
②	CPU + chờ đĩa (iowait)	RRD của Proxmox	Hai đường chồng lên nhau là phép chẩn đoán: CPU thấp mà iowait cao ⇒ đĩa là nút thắt. Tiêu đề ghi cả phần trăm lẫn số luồng (1% · 0.6 luồng).
③	Bộ nhớ	RRD	Phần trăm RAM đã dùng.
④	Mạng	RRD	Hai đường nhận / gửi. Trong RRD netin/netout đã là byte/giây — đừng trừ hai điểm liền nhau.
⑤	Nhiệt độ	B43 tự lấy mẫu (SQLite node_mau)	Mỗi socket một đường — CPU0 xanh dương, CPU1 đỏ. Thang cố định 35…95 °C để hai lần nhìn cách nhau vài giờ so được với nhau. Hai vạch đứt: mát dưới 55° (xanh lá) và tự hạ xung 83° (cam). Mẫu 10 giây khi đang xem, 1 phút khi không.
⑥	GPU	B43 tự lấy mẫu	Tải của card vật lý — khác hẳn tổng các lát vGPU.
⑦	Trung bình tải	RRD	Trần = số luồng (88), không tự co giãn: tải 8 trên máy 88 luồng là nhàn, thang tự co giãn sẽ vẽ nó như kịch khung.

GHI CHÚ · VÌ SAO HAI LOẠI ĐỒ THỊ CÓ ĐỘ MỊN KHÁC NHAU

Proxmox không đo nhiệt độ và tải GPU nên B43 tự lấy mẫu hai thứ đó trong nhịp chung (mục 2.6), giữ nguyên từng mẫu với đúng mốc giây. Bốn đồ thị còn lại là RRD của Proxmox, chỉ mịn tới 60 giây — nhịp 10 giây của B43 không làm chúng mịn hơn được.

▸ Ngưỡng mát dưới 55° = max − 28. Con số 28 dùng chung cho cả vạch trên đồ thị lẫn màu huy hiệu, để không bao giờ có cảnh huy hiệu xanh trong khi đường đã vượt vạch. Đổi từ 15 lên 28 ngày 16/09/2026 theo yêu cầu: hễ có máy ảo chạy là huy hiệu sang vàng.

▸ Màu huy hiệu dùng tông chữ tối riêng (đo ≥ 4,5 : 1) — trước 18/09 chữ vàng trên nền vàng chỉ đạt 1,93 : 1.

11.5 Bảng nhiệt độ chi tiết — và 83 °C, 85 °C nghĩa là gì

Hình 11.6. Bảng nhiệt của pve-001, mở bằng cách BẤM ô Nhiệt CPU. Phần từng nhân dài 44 dòng, cuộn trong bảng.

Số	Nhóm	Nội dung và cách đọc
①	Tiêu đề + nút ✕	Nhiệt độ · WP3_PVE1. Đóng bằng ✕, bấm lại ô, bấm ra ngoài hoặc Esc. Mở bằng bấm chứ không rê chuột: bảng dài phải cuộn, và màn cảm ứng không có thao tác rê.
②	Mỗi socket	Package id 0 71 °C, Package id 1 72 °C, mỗi dòng ghi hạ xung 83° · giới hạn 85°. Đây là số trên hai huy hiệu của thẻ.
③	Linh kiện khác	nvme · Composite 40 °C (ổ NVMe) · nvme · Sensor 1/2 · nct6779 · AUXTIN0/AUXTIN3 (chân đo phụ của chip giám sát trên bo mạch, không gắn nhãn) · nct6779 · PECI Agent 0/1 (nhiệt CPU đọc qua đường PECI của bo mạch — cao hơn số coretemp 5–6 °C vì cách quy đổi, tin số Package) · GPU · GTX 1660 Ti 38 °C (hạ xung 92°, giới hạn 95°).
④	Từng nhân (44)	CPU0 · Core 0… — tên có tiền tố socket vì mỗi socket đánh số nhân lại từ 0; thiếu tiền tố thì hai dòng cùng tên Core 0 với hai nhiệt độ khác nhau.

Mốc	Nguồn	Chuyện thật sự xảy ra
max = 83 °C	temp1_max	CPU tự hạ xung (TCC). Máy vẫn chạy, chỉ chậm đi. Đây là mốc đáng quan tâm hằng ngày.
crit = 85 °C	temp1_crit	Phần cứng cắt điện ngay (THERMTRIP). Không phải khởi động lại — máy tắt và nằm im chờ người bật.
Mốc của ACPI	/sys/class/thermal/	Không có trên máy này: giá trị -274000 (−274 °C, dưới cả độ không tuyệt đối) là cách nhân Linux ghi “chưa đặt”.

NGUY HIỂM · ĐÃ CHẠM 84 °C THẬT — LÚC SAO LƯU ĐÊM

Lịch sử cảnh báo ghi lại: 23:33 ngày 18/09/2026 CPU0 lên 84 °C, về 71 °C lúc 23:37 — đúng cửa sổ sao lưu đêm bắt đầu 23:30. Sáng 19/09 lúc 06:25 CPU0 82 °C, 06:29 CPU1 80 °C, hết lúc 06:37. 84 °C là vượt mốc hạ xung và chỉ còn cách mốc cắt điện 1 °C.

▸ Không có thẻ cảnh báo thì hai lần này không ai biết — cả hai đều lúc không ai mở trang. Mục 15.5 mô tả cơ chế.

▸ Khảo sát trước đó cho thấy tản nhiệt không hỏng; nút thắt là thùng máy thiếu gió và tải vGPU luôn dồn vào socket 1. Chi tiết ở Phụ lục H.1.

Chương 12 — Sao lưu, Dự án, SSH Keys và Marketplace

12.1 Trang Sao lưu

Hình 12.1. Trang Sao lưu ngày 07/09/2026. Dải cảnh báo trên cùng là thành phần quan trọng nhất của trang này — nó vẫn hiện y như vậy mỗi khi có kho không đọc được.

Số	Thành phần	Giải thích
①	.bk-warn — Không đọc được N kho lưu trữ	Bắt buộc phải hiện. GET /api/backups gộp mọi kho có bật nội dung backup trên tất cả node và trả về hai danh sách: items và unavailable. Ở đây pve-wp2-01 / (mọi kho) không đọc được vì node đang tắt.
②	.bk-head — thống kê	“1 bản sao lưu” và “13 GB tổng dung lượng”.
③	#bkNew — Sao lưu ngay…	Mở cửa sổ tạo bản sao lưu mới.
④	#bkBody — bảng	Sáu cột: Máy ảo · Ghi chú · Máy chủ · Kho · Dung lượng · Thời điểm, cộng cột nút Khôi phục / Xoá. Cột Ghi chú bấm được để sửa tại chỗ. (Nay có thêm cột Hạn còn lại — xem hình kế tiếp.)

Trang Sao lưu từ 18/09/2026 — lịch tự động, ba nhóm, hạn còn lại

Hình 12.2. Trang Sao lưu ngày 19/09/2026: 44 bản sao lưu, lịch 23:30 mỗi đêm, tab Hằng ngày đang mở.

Số	Thành phần	Giải thích
①	.bk-head — thống kê	“36 đang hiện · tổng 44” và “647 GB · tổng 777 GB” — số đang hiện theo tab đang chọn, cạnh số tổng của mọi nhóm.
②	#bkNew — Sao lưu ngay…	Như trước.
③	Thẻ Lịch sao lưu tự động	Danh sách job vzdump của Proxmox, từng máy chủ một (các node không lập cụm nên mỗi node có danh sách riêng).
④	Nút Thêm lịch…	Mở hộp tạo lịch — xem hình sau.
⑤	Một dòng lịch	Máy chủ · Lịch · Lần chạy tới · Kho · Phạm vi · Chế độ · Trạng thái. Dòng đang có: pve-001 · Hàng ngày 23:30 · lần tới 23:30 19-09 (2 giờ nữa) — đọc thẳng next-run của Proxmox · pbs · Tất cả máy · snapshot · zstd · Đang bật.
⑥	Bốn nút của dòng	▶ Chạy ngay · Sửa · Tắt/Bật · Xoá. Proxmox không có lệnh “chạy job” — Chạy ngay gọi vzdump với đúng tham số của job.
⑦	Dòng Lần sao lưu gần nhất	“pve-001: 22 giờ trước · 23:30 18-09 — OK 5 phút” — đọc từ tác vụ vzdump gần nhất của node.
⑧	Tab ba nhóm lưu trữ	Hằng ngày 36 · Hằng tuần 6 · Hằng tháng 1 · Vô hạn 1. Tab sinh ra từ luật giữ bản thật của PBS; tắt keep-weekly bên PBS là tab Hằng tuần biến mất. Vô hạn chỉ hiện khi có bản không ai cắt tỉa.
⑨	Dòng giải thích tab	“Bản mới nhất của mỗi ngày, giữ 7 ngày gần nhất…” — số ngày lấy từ luật thật, không viết cứng.
⑩	Cột Hạn còn lại	“6 ngày 3h29” — còn bao lâu nữa thì bản này bị PBS cắt tỉa. Không nơi nào lưu sẵn ngày hết hạn: B43 mô phỏng luật keep-daily 7 · keep-weekly 4 · keep-monthly 6 của PBS để tính.
⑪	Tên máy ở cột đầu	Bấm để xem riêng một máy — hình sau nữa.

LƯU Ý · MỘT BẢN THUỘC ĐÚNG MỘT NHÓM — NHÓM CỦA LUẬT GIỮ NÓ LÂU NHẤT

Bản thuộc Hằng tuần không phải vì nó rơi vào Chủ nhật, mà vì keep-weekly là luật cuối cùng còn giữ nó. Hệ quả hay bị hỏi:

▸ Bản chốt tháng là bản cuối tháng, không phải ngày 01 — PBS giữ bản mới nhất của mỗi tháng.

▸ Tháng đang chạy chưa có bản Hằng tháng là đúng: bản đêm nay còn bị bản đêm mai thay.

▸ Trong một tab mọi Hạn còn lại đồng nhất — trộn bản còn 5 ngày với bản còn 21 ngày chính là thứ đã phải bỏ khi thiết kế.

Hình 12.3. Xem riêng máy vpn-pc-01: có thêm tab Tất cả và mở sẵn ở đó.

Số	Thành phần	Giải thích
①	Nút ← Tất cả máy	Quay về danh sách mọi máy, tab Hằng ngày.
②	Tab Tất cả 7 · Hằng ngày 6 · Hằng tuần 1 · Hằng tháng 0	Vào xem một máy thì thứ người ta muốn là dòng thời gian của máy đó, nên tab Tất cả được mở sẵn.
③	Dòng giải thích	“Toàn bộ bản sao lưu của riêng máy này, mới nhất trước — gồm cả ba nhóm.”
④	Bảng	Cùng cột như bảng chung.

Hộp Thêm lịch sao lưu

Hình 12.4. Hộp Thêm lịch. Ảnh chụp khi lệnh ghi đã bị chặn — không lịch nào được tạo thật.

Số	Ô	Giải thích
①	Máy chủ	Chỉ liệt kê máy chủ đang online. Khi Sửa một lịch có sẵn thì ô này khoá.
②	Kho lưu bản sao lưu	Chỉ kho có bật nội dung backup trên máy chủ đã chọn.
③	Lịch	Sáu mẫu: Hàng ngày 23:30 · Hàng ngày 02:00 · Thứ 2 – Thứ 6, 03:30 · Chủ nhật 01:00 · Ngày 1 hàng tháng, 04:00 · Mỗi giờ — cả sáu đã được Proxmox thật chấp nhận — và Tự ghi… theo cú pháp calendar event của Proxmox. Sai cú pháp thì máy chủ báo ngay khi lưu.
④	Phạm vi	Tất cả máy trên máy chủ này, kể cả máy tạo sau này — hoặc chỉ những máy chọn bên dưới. Ô Trừ máy dùng với lựa chọn đầu. Lịch có sẵn theo dự án thì hiện thêm dòng đó và giữ nguyên.
⑤	Chế độ	Snapshot (máy vẫn chạy) · Suspend (tạm dừng máy khi chụp) · Stop (tắt máy rồi chụp).
⑥	Nén	zstd (mặc định) · lzo · gzip · none.
⑦	Giữ bản cũ (prune)	Mặc định “Để kho tự lo — PBS có luật giữ bản riêng” — đúng với kho pbs. Bốn mức còn lại (Tối thiểu 3 bản … Doanh nghiệp toàn diện 3 bản + 14 ngày + 8 tuần + 24 tháng + 5 năm) dành cho kho thường như local.
⑧	Tạo lịch	Nút lưu. Dưới ô prune còn Ghi chú và ô tick Bật lịch (cuộn trong hộp).

LƯU Ý · BỐN BẪY CỦA API LỊCH SAO LƯU PROXMOX — B43 ĐÃ TỰ LO, NHƯNG ĐỪNG SỬA NGƯỢC LẠI

▸ Proxmox trả prune-backups dạng từ điển khi đọc, nhưng khi ghi lại đòi chuỗi keep-last=3,… — gửi y như nhận về là lỗi 400.

▸ Hỏi một lịch không tồn tại Proxmox trả 500, không phải 404 — B43 tra danh sách trước.

▸ Đổi phạm vi (tất cả ⇄ chọn máy ⇄ dự án) phải gửi kèm delete= gỡ khoá cũ, nếu không Proxmox từ chối vì hai phạm vi mâu thuẫn.

▸ Ghi chú mẫu notes-template có luật riêng (mục 12.1 cửa sổ Sao lưu ngay): sai luật thì vzdump từ chối chạy lúc đến giờ, không báo lúc lưu. B43 lọc trước khi gửi.

Nút Xoá bản sao lưu — nay báo đúng khi việc xoá thất bại

Trước 13/09/2026 nút Xoá luôn báo “Đã xoá”, kể cả khi bản sao lưu vẫn còn nguyên: lệnh xoá của Proxmox chỉ xếp hàng một tác vụ rồi trả HTTP 200 ngay, còn lỗi nằm trong tác vụ chết vài giây sau. Gặp thật với kho pbs: người dùng được báo thành công bốn lần liền. Nay B43 chờ tác vụ (mặc định 25 giây) và có ba kết cục thay vì hai:

Kết cục	Nghĩa
Tác vụ OK	Đã xoá thật.
HTTP 502	Tác vụ hỏng. Nếu vì thiếu quyền, thông báo nói thẳng ba ý: bản sao lưu không bị xoá · đó là cố ý · muốn xoá thật thì vào thẳng PBS, kèm đường đi cụ thể. Thông báo dài nên ở lại 18 giây.
Hết giờ chờ	Tác vụ vẫn đang chạy — không phải lỗi, nhưng cũng không được hứa là đã xong.

ĐÚNG THIẾT KẾ · KHÔNG XOÁ ĐƯỢC BẢN SAO LƯU TỪ B43 LÀ ĐÚNG THIẾT KẾ

Token mà Proxmox dùng để ghi vào PBS chỉ có quyền ghi và đọc, không có quyền xoá. Nhờ vậy một máy chủ Proxmox — hay một B43 — bị chiếm quyền cũng không xoá được bản sao lưu của chính nó. Sổ Hoạt động ngày 19/09 ghi một lần thử như vậy: Xoá bản sao lưu — Lỗi 502, và tác vụ Proxmox tương ứng “proxmox-backup-client failed”. Bản sao lưu vẫn còn.

NGUY HIỂM · VÌ SAO KHO ĐỌC KHÔNG ĐƯỢC PHẢI HIỆN LÊN

Với màn hình sao lưu, thiếu một bản mà không có dấu hiệu gì có thể khiến người dùng kết luận “bản sao lưu đã mất” rồi đi khôi phục từ một bản cũ hơn — và mất đúng phần dữ liệu họ đang cố cứu. Lặng lẽ bỏ qua ở đây tệ hơn nhiều so với báo thừa.

Cửa sổ Sao lưu ngay

Hình 12.5. Bốn lựa chọn: máy ảo, kho đích, cách chụp, và mô tả.

Ô	Giải thích
Máy ảo	Liệt kê mọi máy trên các node đọc được, kèm mã và tên node.
Lưu vào kho	Chỉ hiện các kho có bật nội dung backup. Kho khác không xuất hiện, không phải lỗi.
Cách chụp	Snapshot — máy vẫn chạy (khuyến nghị) · Suspend — tạm dừng máy khi chụp · Stop — tắt máy rồi chụp, an toàn nhất.
Mô tả	“Ghi lại vì sao bạn chụp bản này. Sau vài tháng, tên tệp vzdump-qemu-101-2026_08_30… không nói được điều đó.” Gõ {{guestname}} để tự thay bằng tên máy.

Cập nhật 11/09/2026: ô Lưu vào kho nay có hai lựa chọn pbs | local, trong đó pbs đứng đầu và là lựa chọn nên dùng; ô Máy ảo liệt kê cả hai container mới #200 sharestore-smb và #201 pbs. Bản sao lưu container ghi chữ container cạnh số hiệu và khôi phục được; hộp thoại khôi phục cảnh báo bind mount và IP tĩnh trước khi bấm. Ảnh chụp và lý do ở Phụ lục G.6.

LƯU Ý · CỬA SỔ ĐÓNG ĐƯỢC, VIỆC VẪN CHẠY TIẾP — VÀ CÁI PHANH HTTP 409

GET /api/backups đọc nội dung kho, mà một bản sao lưu chỉ có mặt ở đó khi đã ghi xong. Suốt 2–5 phút vzdump chạy thì bảng không đổi một chữ — và người dùng đọc màn hình im lặng thành “lệnh bị từ chối” rồi bấm lại; mỗi lần bấm là thêm một vzdump nữa cùng cày một ổ đĩa.

▸ GET /api/backups/running hỏi tác vụ đang chạy và moi phần trăm từ log — Proxmox không có API tiến độ. Giao diện vẽ một dòng xanh có thanh tiến độ ở đầu bảng.

▸ Nhịp theo dõi: 4 giây khi đang bận, 15 giây khi rảnh, và ngủ hẳn khi tab bị ẩn.

▸ backup_now từ chối lệnh thứ hai cho cùng một máy bằng HTTP 409, kèm giờ bắt đầu của lệnh đang chạy. Đây là cái phanh, không phải sự bất tiện: hai vzdump chồng nhau làm cả hai chậm gần gấp đôi.

Cửa sổ Khôi phục

Hình 12.6. Hai lựa chọn khôi phục, và dải cảnh báo đỏ chỉ hiện khi chọn Ghi đè.

Lựa chọn	Nghĩa	Rủi ro
Khôi phục thành Máy ảo MỚI	Cấp một mã VMID mới, dựng ra một máy độc lập. Giữ nguyên máy hiện tại.	An toàn. Nhớ đổi địa chỉ IP để tránh xung đột với máy cũ.
Ghi đè lên chính #102	XOÁ SẠCH máy hiện tại rồi dựng lại từ bản sao lưu.	Mọi thay đổi sau thời điểm bản sao lưu sẽ mất vĩnh viễn.
Nơi đặt ổ đĩa	Chọn kho đích (local-lvm hoặc vmstore).	—

NGUY HIỂM · GHI ĐÈ PHẢI ĐƯỢC YÊU CẦU MINH THỊ Ở TẦNG BACKEND

Backend bắt buộc đòi tham số overwrite_existing=true, và cố ý không suy ra từ việc vmid trùng một máy đang tồn tại. Nếu ai đó “tối ưu” chỗ này thành suy ra ngầm, thì một cú bấm nhầm sẽ xoá sạch một máy đang chạy — đó là lỗi nghiêm trọng, không phải cải tiến.

12.2 Trang Dự án

Hình 12.7. Trang Dự án: phần dẫn nhập ở trên, rồi mỗi dự án một thẻ.

Hình 12.8. Bảng 9 màu, ô xem trước nhãn, cảnh báo “thiếu ở node kia” kèm nút Tạo nốt, và danh sách máy thành viên.

Thành phần	Giải thích
#pjNew — Tạo dự án mới	Tạo pool mới trên mọi node đọc được.
Tên dự án (.pj-name-edit)	Bấm vào là sửa tại chỗ. Đổi tên thì màu đi theo — nếu không, nhãn sẽ lặng lẽ nhảy về xanh dương và người dùng tưởng bị mất.
Mô tả (.pj-desc-edit)	Cũng sửa tại chỗ. Ghi vào trường comment của pool.
Bảng 9 màu	Đỏ · Cam · Hổ phách · Xanh lục · Xanh ngọc · Xanh dương · Tím · Hồng · Xám đá. Là danh sách đóng, không cho nhập mã màu tự do.
Ô xem trước	Hiện nhãn thật với màu đang chọn, ngay cạnh bảng màu.
.pj-warn — Tạo nốt	Cảnh báo dự án mới chỉ có ở pve-wp2-02, thiếu ở pve-wp2-01. Máy ảo ở node kia không gán vào được cho tới khi bấm nút này.
Danh sách máy (.pj-vm)	Tên, mã, node, trạng thái, và nút Chuyển…
Xem máy / Xoá dự án	Lọc bảng Droplets theo dự án này / xoá pool.

GHI CHÚ · VÌ SAO BẢNG MÀU LÀ DANH SÁCH ĐÓNG, VÀ VÌ SAO MÀU KHÔNG NẰM TRÊN PROXMOX

Nhãn phải đọc được trên cả giao diện sáng lẫn tối, nên mỗi màu là một bộ ba (nền, chữ, viền) khai riêng cho từng giao diện. Cho chọn mã màu tự do thì sớm muộn cũng có một dự án màu vàng chanh biến mất hoàn toàn trên nền sáng.

▸ Pool của Proxmox chỉ có hai ô: poolid và comment. comment đã dùng làm mô tả dự án; nhét mã màu vào đó là làm hỏng một trường đang có nghĩa.

▸ Vì vậy màu nằm ở /data/project_meta.json, cùng chỗ với vgpu_choice.json.

LƯU Ý · MỘT MÁY CHỈ THUỘC MỘT POOL, VÀ PROXMOX KHÔNG TỰ CHUYỂN

Thêm vào pool mới khi máy còn ở pool cũ sẽ bị từ chối. Vì vậy hàm assign_project phải gỡ khỏi pool cũ trước, rồi mới thêm vào pool mới. Đây là lý do thao tác chuyển dự án gồm hai lời gọi chứ không phải một.

Trang Dự án không liệt kê bản mẫu vào nhóm “chưa thuộc dự án nào”. Bảng Droplets đã cố ý lọc bản mẫu ra sau hai lần bị xoá nhầm; để chúng nằm trong danh sách “chưa xếp” là mời người dùng bấm vào đúng thứ nguy hiểm nhất.

12.3 Trang SSH Keys

Hình 12.10. Kho khoá công khai dùng chung. Vân tay hiển thị dạng hex có dấu hai chấm.

Cột / nút	Giải thích
Tên	Tên gợi nhớ do người dùng đặt, ví dụ meomay22@WP3-PC1. Chỉ để phân biệt khoá của máy nào.
Fingerprint	Vân tay khoá, ví dụ b0:c6:7f:68:46:3b:…. B43 tính bằng MD5 của phần base64 — đây là dạng vân tay cổ điển của OpenSSH, khác với dạng SHA256: mà OpenSSH đời mới in ra mặc định.
Ngày thêm	Định dạng Việt Nam.
#addKey	Nút Thêm khoá.

Hình 12.11. Cửa sổ thêm khoá, kèm hướng dẫn sinh khoá chép được ngay trong khung.

Mã HTML	Ô	Giải thích
.help-inline	Khung hướng dẫn	Có sẵn hai lệnh: ssh-keygen -t ed25519 để sinh khoá, rồi cat ~/.ssh/id_ed25519.pub để lấy nội dung chép.
#kName	Tên gợi nhớ	“Chỉ để bạn phân biệt khoá của máy nào. Đặt gì cũng được.”
#kBody	Nội dung khoá công khai	Một dòng duy nhất, bắt đầu bằng ssh-ed25519 AAAA… hoặc ssh-rsa AAAA….

NGUY HIỂM · CHỈ DÁN KHOÁ CÔNG KHAI

Khung hướng dẫn nói thẳng: “File không có đuôi .pub là khoá riêng, giữ trên máy, đừng dán vào đâu cả.” Dán nhầm khoá riêng vào đây là trao chìa khoá của chính bạn cho mọi người đọc được kho /data.

▸ Trên Linux/macOS, sau khi sinh khoá phải đặt quyền chmod 600 ~/.ssh/id_ed25519. Để 644 hay 777 thì OpenSSH từ chối kết nối: “Permissions 0644 for id_ed25519 are too open!”

▸ Khoá riêng của chính container B43 (ssh/id_ed25519, dùng để chạy qm monitor trên node) phải chmod 600 + chown 1000:1000 — container chạy uid 1000. Sai quyền thì OpenSSH báo “Permission denied (publickey)”, trông y hệt sai mật khẩu.

12.4 Trang Marketplace — và điều nó KHÔNG làm

Hình 12.12. Trang Marketplace: cảnh báo điều kiện tiên quyết, hai tab, 11 chip phân loại và lưới thẻ ứng dụng.

NGUY HIỂM · TRANG NÀY KHÔNG TẠO MÁY

Nó sinh lệnh docker run / docker compose để bạn dán vào một máy đã có. Chờ nó dựng ra một Droplet là hiểu sai chức năng. Muốn “một nút ra ứng dụng chạy được” thì đó là tab Ứng dụng TurnKey ở trang Tạo Droplet.

Số	Thành phần	Giải thích
①	.mk-ssh-alert	“Trước khi triển khai: máy ảo đích bắt buộc phải bật SSH và đã cài Docker.”
②	#mkTabs	Hai tab: Ứng dụng dựng sẵn (13 mục) và Tìm trên Docker Hub.
③	#mkCats2	Mười một chip phân loại: Tất cả · Web Server · CMS · Database · Database/Cache · Automation · Management · Monitoring · Cloud Storage · DevOps · Storage.
④	#mkList	Lưới thẻ ứng dụng. Mỗi thẻ có: biểu tượng, tên, nhãn phân loại, mô tả tiếng Việt, tên ảnh Docker (nginx:latest), RAM tối thiểu, các cổng (80→80, 443→443) và nút Xem lệnh triển khai.

Hình 12.13. Cửa sổ lệnh triển khai: cả docker run lẫn docker-compose.yml, mỗi khối một nút Chép.

ĐÚNG THIẾT KẾ · LỆNH SINH RA ĐÃ TUÂN THỦ QUY ƯỚC MÚI GIỜ CỦA HỆ THỐNG

Khối docker-compose.yml sinh ra đã có sẵn cả ba dòng bắt buộc: TZ=Asia/Ho_Chi_Minh, gắn /etc/localtime và gắn /usr/share/zoneinfo. Thiếu dòng thứ ba là ảnh nền Alpine/musl sẽ ra +0000 — tệ hơn không đặt gì.

Chương 13 — Bản mẫu và cây phả hệ

13.1 Bản mẫu là gì, và vì sao nó nguy hiểm

Proxmox không coi bản mẫu là một tệp ảnh riêng. Nó vẫn là một máy ảo, chỉ thêm template: 1 trong cấu hình và đổi tên ổ thành base-<vmid>-disk-N (chỉ đọc). Chính vì trông y hệt một máy đang tắt mà nó từng bị xoá nhầm hai lần.

Thành phần	Giải thích
Thẻ bản mẫu	template01-win10-gpu #102 trên pve-wp2-02 — 8 vCPU, 16 GB RAM, 32 GB đĩa, tạo 02/09/2026.
Đổi tên / Sửa ghi chú	Ghi chú là chỗ mô tả bản mẫu chứa gì. Ví dụ thật: “Bản mẫu Windows 10 đời đầu. Cần mount đĩa CD và cài win10_setup.bat…”
N máy đang tựa vào đĩa	Đếm chính xác bao nhiêu máy con đang dựa vào đĩa của bản mẫu này qua cơ chế nhân bản liên kết.
Tạo máy từ mẫu này	Nhân bản ra một máy mới.
Máy mất gốc	Sổ có ghi các máy này sinh ra từ một bản mẫu, nhưng bản mẫu đó không còn trên máy chủ nữa. Máy vẫn chạy bình thường — chỉ là không nhân bản thêm từ cùng một gốc được.
Xem cấu trúc →	Chuyển sang chế độ cây phả hệ.

LƯU Ý · CÂU CẢNH BÁO NGUYÊN VĂN TRÊN TRANG, ĐÁNG ĐỌC KỸ

“Proxmox vẫn cho xoá bản mẫu này và sẽ không hỏi lại. Máy con không chết, dữ liệu còn nguyên — nhưng dấu vết chúng sinh ra từ đâu thì mất vĩnh viễn, trừ những cạnh B43 đã kịp ghi sổ.”

13.2 Cây phả hệ — ghép từ hai nguồn, mỗi nguồn một tính chất

Hình 13.2. Hai nguồn dữ liệu và ba kiểu nét đường. REST API của Proxmox KHÔNG có trường nào cho quan hệ cha–con, nên cả hai nguồn đều phải tự dựng.

Hình 13.3. Cây phả hệ thật: bản mẫu #102 → máy con #103 → ba ảnh chụp, cùng một máy #100 đầy đủ.

Số	Thành phần	Giải thích
①	.cay-bar	Ô lọc theo dự án (kèm số máy) và ô tick hiện/ẩn ảnh chụp. Lọc giữ lại tổ tiên (bản mẫu làm giàn, được làm mờ) và hậu duệ (ảnh chụp đi theo máy).
②	.cay-legend	Chú giải hai nhóm: bốn kiểu nút và ba kiểu nét đường (đo được · chỉ sổ nhớ · không rõ).
③	.cay-wrap	Thân cây. Mỗi hàng: biểu tượng trạng thái, tên (bấm được), mã máy, chip loại (bản mẫu / liên kết / đầy đủ), nhãn nguồn (ghi sổ / dò ngược), và nhãn dự án.
④	.cay-act	Thanh thao tác. Chưa chọn gì thì hiện hướng dẫn; chọn một hàng thì hiện các nút áp dụng cho hàng đó.

Hình 13.4. Sau khi chọn bản mẫu #102, thanh thao tác hiện đúng những nút áp dụng được cho nó.

Nguồn	Cách lấy	Tính chất	Nét vẽ
DÒ NGƯỢC	lvs -o origin qua SSH	Đo được ở hiện tại, chính xác tuyệt đối. MẤT khi bản mẫu cha bị xoá.	Nét liền
GHI SỔ	/data/lineage.json, ghi lúc nhân bản	Bền, sống sót khi cha bị xoá. Chỉ có với máy do chính B43 nhân bản.	Nét đứt
Không rõ	—	Không nguồn nào khẳng định được.	Nét chấm

GHI CHÚ · ẢNH CHỤP CŨNG LÀ MỘT NHÁNH CỦA CÂY, VÀ CÂY CÓ NHÁNH THẬT SAU ROLLBACK

Ảnh chụp của một máy hiện thành các hàng con của máy đó, kèm nhãn “máy đang đứng ở đây” đánh dấu vị trí hiện tại (giống HEAD trong git). Sau khi khôi phục về một ảnh chụp cũ rồi làm tiếp, cây rẽ nhánh thật — dựng từ trường parent mà Proxmox ghi trong cấu hình snapshot.

Kiểu nhân bản	Luật do KHO quyết định	Chi phí đĩa
Liên kết (linked)	Chỉ tạo được từ đĩa base-* hoặc từ một ảnh chụp	0 GB lúc đầu, chỉ ghi phần khác biệt
Đầy đủ (full)	Từ đâu cũng được	Chép trọn dữ liệu (đo thật: 22,15 GB)

NGUY HIỂM · THAO TÁC PHÁ HUỶ TRÊN CÂY BẮT GÕ LẠI MẬT KHẨU

Nút Xoá bản mẫu / Xoá ảnh chụp trong thanh thao tác yêu cầu gõ lại mật khẩu đăng nhập, và mật khẩu được kiểm ngay trong endpoint phá huỷ chứ không phải chỉ ở giao diện; kèm theo là một bộ hãm chống dò. Lý do: một hộp thoại “bạn có chắc không?” là thứ ai cũng bấm Yes theo phản xạ sau lần thứ ba.

ĐÚNG THIẾT KẾ · XOÁ XONG MÀ CÂY CÒN GIỮ LẠI TỚI 47 GIÂY — ĐÚNG, KHÔNG PHẢI LỖI

Hai nguyên nhân chồng nhau: bản đệm live: còn hạn, và luồng dò ngược qua SSH chưa chạy lại. Bấm ↻ Làm mới là thấy ngay.

Chương 14 — Cấu hình máy chủ — card đồ hoạ và cổng USB

Từ 17/09/2026 trang có hai tab ngay dưới ô chọn máy chủ: Card đồ hoạ (vGPU) — toàn bộ nội dung mục 14.1–14.2 — và Cổng USB (mục 14.3). Tiêu đề phụ của trang đổi thành “Card đồ hoạ và cổng USB”.

Hình 14.1. Đầu trang: chọn node, rồi chọn cách dùng card đồ hoạ. Tên card thật hiện ngay trên tiêu đề khối.

Thành phần	Giải thích
#scNodes	Lưới chọn node. Chỉ hiện node đang trực tuyến — cấu hình card đòi chạy lệnh trên máy chủ.
Huy hiệu tên card	NVIDIA Corporation TU116 [GeForce GTX 1660 Ti] (rev a1) — đọc trực tiếp từ máy chủ, không phải điền cứng.
#gpuModeSwitch	Hai chế độ loại trừ nhau, xem bảng bên dưới.

Đặc tính	Chia nhiều vGPU	Passthrough nguyên card
Số máy ảo cùng lúc	Nhiều máy chia sẻ một card	Đúng một máy sở hữu card
Driver máy chủ	Cần driver NVIDIA vGPU Manager (bản vá vgpu_unlock)	Dùng driver vfio-pci chuẩn của nhân Linux, gỡ liên kết driver nvidia
Driver máy khách	Driver GRID — máy ảo nhìn card như Quadro RTX 6000	Driver GeForce chính thức, như máy thật
Giấy phép	Cần — và hết hạn được	Không cần, không hết hạn
Hợp với	Nhiều máy văn phòng, máy chạy trình duyệt, giả lập	Máy trạm dựng hình, huấn luyện AI, chơi game

Hình 14.2. Chế độ Passthrough: khối chia lát biến mất hoàn toàn, thay bằng phần gán card cho một máy ảo duy nhất.

14.1 Bảng “Cấu hình đang áp dụng”

Hình 14.3. Bảng này trả lời câu hỏi vì sao nvidia-smi trong máy khách báo 928 MiB chứ không phải 1024 MiB.

Bốn cột: Profile · VRAM máy ảo thấy · GPU giữ lại · Tổng mỗi vGPU. Với cấu hình hiện tại: nvidia-256 · 928 MiB · 96 MiB · 1024 MiB. Dòng chú thích bên dưới: “Tổng cộng 1 vGPU đang được khai báo.”

14.2 Khối chia lại card

Hình 14.4. Toàn bộ khối chia lát: tổng VRAM, số lát, bốn cách chia gợi ý, ba kiểu vGPU và bản xem trước.

Mã HTML	Thành phần	Giải thích
#scVram	Tổng VRAM của card (MiB)	Đọc từ nvidia-smi trên máy chủ: 6144 MiB. “Khai nhiều hơn dung lượng thật thì driver vẫn nhận cấu hình nhưng máy ảo không khởi động nổi — nên ô này chặn ở đúng con số đó.” Lưu ý kỹ thuật: thuộc tính max= của ô số chỉ đánh dấu form không hợp lệ, người dùng vẫn gõ được ⇒ phải tự kẹp bằng JavaScript.
#scN / #scMax	Số vGPU muốn chia	Thanh trượt 1 → 6. “Trần = VRAM ÷ 1 GB — dưới 1 GB mỗi máy thì driver từ chối.”
#scPresets	Bốn cách chia gợi ý	1× 6GB (hiệu năng tối đa cho một máy đồ hoạ nặng) · 2× 3GB · 3× 2GB · 6× 1GB (tối đa số lượng máy ảo nhẹ — đang chọn). Gợi ý được sinh theo VRAM thật của từng card, không điền cứng.
#scSeries	Kiểu vGPU	Ba dòng A / B / Q — xem bảng ở mục 5.3. Dòng chú thích đổi theo lựa chọn.
#scPreview	Bản xem trước	“Kết quả sẽ là:” Mỗi vGPU 1024 MiB · Tổng dùng 6144 / 6144 MiB · framebuffer 0x3A000000 · reservation 0x6000000. Đây chính là nội dung sẽ ghi vào /etc/vgpu_unlock/profile_override.toml trên máy chủ.
.sc-now	Hồ sơ đã chốt cho trang Tạo Droplet	“Đang dùng: nvidia-256, chia 6” kèm nút Bỏ chốt. Chốt không ghi gì lên máy chủ — chỉ ghi nhớ trong /data/vgpu_choice.json.
#scApply	Áp dụng cấu hình	Ghi tệp cấu hình xuống máy chủ.

Hình 14.5. Cuối trang: cảnh báo vàng liệt kê đích danh những máy đang giữ card.

LƯU Ý · CẢNH BÁO NGUYÊN VĂN KHI CARD ĐANG BỊ GIỮ

“3 máy ảo đang giữ card (#100 may-goc-gpu-gpm, #102 template01-win10-gpu, #103 vpn-pc-01). Cấu hình mới chỉ có hiệu lực sau khi tắt hết các máy này rồi khởi động lại nvidia-vgpud. Ghi đè khi máy còn chạy không làm hỏng gì, nhưng cũng không đổi được gì.”

▸ Đây là chỗ hay mất thời gian nhất: bấm Áp dụng, thấy báo thành công, rồi tưởng đã đổi xong — trong khi thực tế chưa có gì đổi cả.

▸ Khối chia lát này chỉ hiện với card NVIDIA. Node Intel không có profile_override.toml để ghi.

NGUY HIỂM · BÀI HỌC KỸ THUẬT: ĐIỀU KIỆN VẼ PHẢI GIỐNG HỆT ĐIỀU KIỆN GẮN SỰ KIỆN

Trang này từng chết lặng hoàn toàn trên node Intel: khối chia lát được gate bằng biến canSplit, nhưng đoạn gắn sự kiện chỉ gate bằng isPass ⇒ $('#scN') là null, cả hàm ném lỗi và mọi thứ gắn sau đó không chạy. Không có thông báo lỗi nào cho người dùng. Khi kiểm thử trang này, bắt buộc phải kiểm cả hai node — lỗi chỉ lộ ra ở node Intel.

14.3 Tab Cổng USB — gán từng cổng vật lý cho máy ảo

Proxmox nhận hai kiểu gán USB: theo cổng (usb0: host=3-4 — cắm gì vào lỗ đó cũng vào máy ảo) và theo thiết bị (usb0: host=046d:c52b — thiết bị cắm cổng nào cũng theo). B43 tạo kiểu theo cổng, vì đó mới là điều người dùng mô tả: “cái lỗ này thuộc về máy 103”.

Hình 14.6. Tab Cổng USB của pve-001 ngày 19/09/2026: 23 cổng dùng được, chưa cổng nào gán, chưa cắm thiết bị.

Số	Thành phần	Giải thích
①	Tab Card đồ hoạ (vGPU)	Mục 14.1 – 14.2.
②	Tab Cổng USB	Tab đang mở.
③	Tiêu đề Gán cổng USB cho máy ảo	—
④	Huy hiệu 0/23 cổng đã gán	Số cổng dùng được trên máy chủ này. Máy chủ có 31 cổng; 8 cổng bị loại có lý do (bảng dưới).
⑤	Dòng hướng dẫn vàng	“Cắm thiết bị vào máy chủ trước, rồi mở lại trang này. Thiết bị hiện ở dòng nào thì đó chính là cổng của nó…” — đây là toàn bộ quy trình: cắm thử, nhìn, gán. Không cần bảng tra tên cổng nào.
⑥	Cột Cổng	Đường cổng do nhân Linux đặt (1-2, 3-4…) — không bao giờ trôi. Cố ý không đánh số lại thành USB0, USB1: cắm thêm một thiết bị là mọi số phía sau tụt một bậc, và người dùng gán nhầm mà không chỗ nào lộ ra. Xếp theo số (3-9 trước 3-10).
⑦	Cột Đang cắm	Tên thiết bị đang cắm, hoặc (chưa cắm gì) — cổng trống vẫn hiện.
⑧	Cột Gán cho máy ảo	Ô chọn — không gán — hoặc một máy, kèm · đang chạy. Một cổng đang gán cho máy A mà chọn máy B: B43 tự gỡ khỏi A trước — Proxmox không chặn hai máy khai cùng một cổng, và máy bật sau sẽ giành mất.
⑨	Cột Khe	Khe usbN trong cấu hình máy ảo đã nhận cổng này.

Cổng bị loại	Ví dụ trên pve-001	Vì sao
Hub tích hợp của chipset	1-1, 2-1	Không phải lỗ cắm trên vỏ máy; thiết bị thật hiện ở cổng khác.
Cổng trên chính card đồ hoạ	5-1 … 6-4	Card NVIDIA có bộ điều khiển USB-C riêng; card đã giao cho máy ảo nên các cổng đó đi theo card. So địa chỉ PCI phải bỏ phần .hàm (81:00.0 với 81:00.2), không thì không bao giờ khớp.

NGUY HIỂM · ĐỪNG TIN VỊ TRÍ CỔNG MÀ BIOS KHAI

Chuẩn ACPI cho phép BIOS khai vị trí thật của từng cổng. Bo mạch HUANANZHI X99-T8D có khai, nhưng khai rác: cả 22 cổng đều ghi panel = top, 22 cổng ghi hardwired (nghĩa là “người dùng không với tới”). Lọc theo trường đó là ẩn sạch mọi cổng, tính năng thành trang trắng. B43 chỉ đọc ra cho biết, tuyệt đối không lọc theo.

▸ Một lỗ cắm có thể mang hai tên cổng: USB 2.0 ở bus 3, USB 3.0 ở bus 4. Cắm vào mà máy ảo không thấy thì quay lại xem thiết bị đang nằm ở dòng nào rồi gán thêm dòng đó.

▸ Cổng USB 3 được tự thêm usb3=1 — thiếu cờ này thiết bị vẫn chạy nhưng tụt xuống tốc độ USB 2.

▸ Máy Windows 10/11 và Linux nhận tới 14 khe USB; máy đời cũ hơn chỉ 5.

▸ Chưa kiểm được vì không ai ở cạnh máy: cắm thiết bị thật rồi xem máy khách có nhận không.

Chương 15 — Các lớp bảo vệ đã cài sẵn

Phần này trả lời câu hỏi “hệ thống đang bảo vệ tôi khỏi những gì?”. Mỗi lớp dưới đây sinh ra từ một sự cố có thật, không phải nghĩ ra cho đủ danh sách.

Hình 15.1. Mười hai lớp bảo vệ — ba lớp cuối thêm ngày 18/09/2026 — cơ chế cụ thể của từng lớp, và sự cố đã sinh ra nó.

15.1 Bốn nguyên tắc thiết kế nằm sau mười hai lớp đó

15.2 Xác thực và phiên làm việc

Cơ chế	Chi tiết
Đăng nhập	POST /api/login với B43_AUTH_USER / B43_AUTH_PASSWORD. Cấp cookie phiên b43_session ký bằng HMAC.
Thời hạn	30 ngày nếu tích Ghi nhớ máy này; huỷ khi đóng trình duyệt nếu bỏ tích.
Đường không cần cookie	Năm đường cố định: /api/auth/state, /api/login, /api/logout, /login.html và /api/health (cho bộ kiểm sức khoẻ của Docker — chưa đăng nhập chỉ nhận {"status": "ok"}); cộng một tiền tố /api/vgpu-driver/ để chính máy ảo tải driver về cài. Mọi đường còn lại đều bị chặn. (Bản 13/09 ghi “đúng ba” là thiếu.) Từ 18/09 có test tự động test_duong_mien_dang_nhap_khong_moc_them — ai thêm một đường vào danh sách này mà không sửa test là test đỏ.
Lớp thứ hai (từ 18/09/2026)	Khi 2FA bật: mật khẩu đúng mà thiếu mã ⇒ 401 + need_totp; mã sai tính như mật khẩu sai. Mục 15.3.
Chưa đăng nhập	Mọi route bị 302 sang /login.html, kèm tham số next đã được kiểm là đường dẫn nội bộ.
Không đặt mật khẩu	Xác thực tự tắt (để người quản trị không tự khoá cửa chính mình), nhưng dải băng đỏ #noAuthBar hiện ở đầu mọi trang và khối tên người dùng ở chân thanh bên biến mất.

NGUY HIỂM · CONSOLE PROXY LÀ CỬA QUYỀN LỰC NHẤT CỦA B43

Đường console chuyển tiếp phiên root@pam của chính B43 cho bất kỳ trình duyệt nào mở được B43. Nó không tạo ra một cửa mới (ai vào được B43 vốn đã điều khiển được máy ảo), nhưng nó làm mọi khuyến cáo về việc không đưa cổng 20430 ra Internet trở nên nghiêm túc hơn nhiều. Tắt riêng đường này bằng B43_CONSOLE_PROXY=0.

▸ Rà soát 18/09/2026 phát hiện B43 ĐANG có đường vào từ Internet — không qua cổng 20430 mà qua Caddy cổng 443 (b43.lotuscloud.lotus1104.synology.me, cần cho console noVNC chạy HTTPS). Câu “cổng 20430 không mở” vẫn đúng nhưng không còn đủ. Đó là lý do lớp 2FA ở mục 15.3 được làm trước mọi thứ khác.

15.3 Xác thực hai lớp — trang Bảo mật

Mở bằng cách bấm tên người dùng ở chân thanh bên (#/security). Chuẩn TOTP (RFC 6238) — dùng được với Google Authenticator, Aegis, Microsoft Authenticator, 1Password. Thuật toán viết thẳng bằng thư viện chuẩn của Python (khoảng hai mươi dòng), chỉ thêm gói qrcode để vẽ mã QR.

Hình 15.2. Trang Bảo mật khi 2FA đang bật (bật lúc 13:08:50 ngày 18/09/2026). Không có khoá bí mật nào hiện trên trang ở trạng thái này.

Số	Thành phần	Giải thích
①	Tiêu đề Xác thực hai lớp (TOTP) + chấm ?	Chấm ? mở hướng dẫn đầy đủ.
②	Huy hiệu Đang bật / Đang tắt	Đọc lại từ /data/totp.json mỗi lần — không nhớ trong bộ nhớ, để đường cứu ở ⑥ có hiệu lực ngay.
③	Đoạn giải thích	“…Kẻ biết mật khẩu mà không cầm điện thoại của bạn vẫn đứng ngoài. Trang này có đường vào từ Internet qua Caddy, nên lớp thứ hai không phải thứ trang trí.”
④	Dòng thời điểm	“Đang bật từ 13:08:50 18/9/2026. Phiên đang mở không bị ảnh hưởng; lần đăng nhập tới sẽ hỏi mã.”
⑤	Nút Tắt xác thực hai lớp…	Đòi một mã đúng — ai mượn được một phiên đang mở cũng không tắt được.
⑥	Dòng Mất điện thoại?	docker exec lotus_cloud rm /data/totp.json — có hiệu lực ngay, không cần khởi động lại. Chỉ ai có quyền trên HP1 mới làm được.

Bước bật	Chuyện xảy ra phía sau
Bấm Bật	B43 sinh khoá 32 ký tự base32 ở trạng thái chờ, hiện mã QR + chuỗi khoá (để gõ tay khi không quét được). Khoá chờ sống 15 phút.
Quét QR, gõ 6 số, bấm Xác nhận	Chỉ khi mã đúng khoá mới thành thật. Quét nhầm QR hay bỏ dở giữa chừng thì không tự khoá mình ra ngoài.
Đăng nhập lần sau	Hỏi mã (mục 6.1). Chấp nhận mã của bước liền trước/sau (điện thoại lệch giờ tới 30 giây). Mã đã dùng thì không dùng lại được trong cùng 30 giây.

15.4 Sổ Hoạt động — ai làm gì, lúc nào

Proxmox chỉ thấy một người dùng — root@pam của B43 — nên câu hỏi “ai xoá máy này?” không có lời đáp ở phía Proxmox. Trang #/activity có hai tab từ hai nguồn khác nhau:

Hình 15.3. Tab Thao tác trên B43 (129 dòng lúc chụp, tối 19/09/2026). Các dòng đầu là chính những lần đăng nhập của phiên chụp ảnh này — mỗi lần là một cặp “chờ mã 2FA” rồi “OK”. Tab Tác vụ Proxmox ghi (0) vì lúc chụp pve-001 đang mất liên lạc; hình sau chụp lúc máy còn chạy.

Số	Thành phần	Giải thích
①	Tab Thao tác trên B43 (N)	Sổ do chính B43 ghi: mọi lệnh POST/PUT/DELETE dưới /api/.
②	Tab Tác vụ Proxmox (N)	Sổ của hypervisor, gộp từ mọi node — hình sau.
③	Dòng nhắc	“Proxmox chỉ thấy root@pam — cột Ai chỉ có ở đây.”
④	Cột Lúc	Tương đối + tuyệt đối: “2 phút trước · 21:29 19-09”.
⑤	Cột Ai	Tài khoản đăng nhập B43.
⑥	Cột Từ	IP gửi lệnh. 114.114.114.254 là cổng mạng nội bộ Docker — lệnh từ một container khác trên HP1 (như trình duyệt B35 dùng để chụp ảnh sách này) hiện như vậy; một IP công cộng (như 42.114.25.97) là lệnh đi vào từ Internet.
⑦	Cột Việc	Tên việc bằng tiếng Việt (Đăng nhập, Chia vGPU, Xoá bản sao lưu…), dịch từ đường dẫn API.
⑧	Cột Máy	Node và mã máy nếu lệnh nhắm vào một máy.
⑨	Cột Kết quả	OK, Chờ mã, Sai, Lỗi 502… Lỗi thì kèm câu detail của máy chủ (rê chuột lên huy hiệu).
⑩	Cột ms	Thời gian máy chủ xử lý.
⑪	Huy hiệu xám Chờ mã	Bước 1/2 khi 2FA bật: mật khẩu đúng, máy chủ hỏi tiếp mã. Không phải lần sai, nên dòng này không tô đỏ.
	Dòng có viền đỏ bên trái	Lệnh không thành (không có trong khung ảnh này). Sai = mật khẩu hoặc mã 2FA sai; Lỗi N = máy chủ từ chối hoặc hỏng.

LƯU Ý · MỘT LẦN ĐĂNG NHẬP 2FA HIỆN THÀNH HAI DÒNG — DÒNG ĐẦU LÀ BƯỚC CHỜ MÃ

Bước đầu (mật khẩu đúng, chưa có mã) máy chủ trả 401 kèm need_totp. Từ tối 19/09/2026 sổ đánh dấu bước này (cho_ma trong nhat_ky.jsonl) và hiện Đăng nhập — mật khẩu đúng, chờ mã 2FA với huy hiệu xám Chờ mã; dòng cũ hơn được nhận theo câu trả lời của máy chủ. Bộ đếm chống dò mật khẩu cũng không tính bước này. Muốn biết có ai dò thật: tìm dòng Đăng nhập thất bại — Sai, nhất là từ IP lạ — dòng đó giờ chỉ còn là mật khẩu sai hoặc mã sai thật.

▸ Thân lệnh không bao giờ ghi nguyên văn. Chỉ khoá nằm trong danh sách an toàn (name, vmid, node, storage, mode…) mới được tóm tắt; mật khẩu, mã 2FA, khoá SSH không thể lọt vào sổ dù ai thêm endpoint mới — có test tự động canh.

▸ Sổ nằm ở /data/nhat_ky.jsonl, tự xoay vòng ở 5 MB (giữ một bản cũ .jsonl.1). Dòng cụt vì mất điện bị bỏ qua, không làm hỏng cả trang.

Hình 15.4. Tab Tác vụ Proxmox: sao lưu đêm 23:30 OK 288 giây, và một lần xoá bản sao lưu bị PBS từ chối.

Số	Cột	Giải thích
①	Bắt đầu	Giờ tác vụ bắt đầu.
②	Node	Máy chủ chạy tác vụ.
③	Tác vụ	Loại tác vụ Proxmox dịch sang tiếng Việt: Sao lưu, Bật máy, Xoá ảnh đĩa, Cập nhật apt… Kể cả việc bấm thẳng trên giao diện Proxmox hay lịch tự chạy.
④	Máy	Máy ảo liên quan.
⑤	Người	Luôn là root@pam với việc từ B43 — xem tab kia để biết ai.
⑥	Kết quả	OK hoặc nguyên văn lỗi của Proxmox.
⑦	Thời lượng	Giây.
⑧	Dòng lỗi	Ví dụ ngày chụp: Xoá ảnh đĩa 104@pbs — proxmox-backup-client failed — chính là lần xoá bị chặn có chủ ý ở mục 12.1. Lúc chụp tab gộp 150 tác vụ gần nhất.

Đọc sự cố thế nào: thấy một máy biến mất ⇒ mở tab B43, tìm Xoá máy — biết ai, lúc nào, từ đâu. Không có dòng nào ⇒ mở tab Proxmox, tìm Xoá máy: việc đó làm ngoài B43.

15.5 Cảnh báo chủ động — báo cả khi không ai đang xem

Mọi lớp ở trên chỉ có tác dụng khi có người nhìn. Lớp này thì ngược lại: B43 tự đánh giá sau mỗi lượt nhịp chung (mục 2.6) và gửi tin ra ngoài.

Hình 15.5. Vòng đời một cảnh báo và sáu luật đang chạy. Các con số lấy từ canh_bao.py.

Hình 15.6. Trang Cảnh báo ngày 19/09/2026 lúc yên ổn; lịch sử có 14 sự kiện thật.

Số	Thành phần	Giải thích
①	Đang cảnh báo (N) + chấm ?	Số cảnh báo đang mở — bằng đúng số đỏ trên thanh bên.
②	Dòng Không có gì đáng lo	Hiện khi không có cảnh báo nào, ghi luôn các ngưỡng đang áp dụng.
③	Nút Gửi tin thử	Gửi một tin thử tới mọi nơi đã cấu hình. Mờ khi chưa cấu hình nơi nào ngoài bảng này.
④	Hàng Bảng này — luôn bật	Không cần cấu hình gì.
⑤	Hàng Telegram	chưa / đã cấu hình — biến B43_TELEGRAM_BOT_TOKEN + …_CHAT_ID.
⑥	Hàng Slack	Biến B43_SLACK_WEBHOOK = URL Incoming Webhook. Gói gửi đi chỉ có text theo cú pháp của Slack — Slack không hứa bỏ qua trường lạ.
⑦	Hàng Webhook	Biến B43_ALERT_WEBHOOK — nhận POST JSON {nguon, text, su_kien[], luc} cho n8n, Discord…
⑧	Dòng ngưỡng	“nhiệt ≥ 80 °C mỗi socket · kho ≥ 80 % · phải thấy 2 lượt liên tiếp mới báo · đang còn thì nhắc lại mỗi 6 giờ.”
⑨	Lịch sử (N)	Mọi lần bật, hết, nhắc, một lần — giữ 300 dòng.

Hình 15.7. Cảnh báo đang mở — ảnh chụp thật ngày 18/09/2026 lúc kiểm thử có chủ ý: hạ ngưỡng kho xuống 30 % để kho local và ổ hệ điều hành (35 %) kích hoạt. Số đỏ 2 trên thanh bên.

Thẻ vàng là cảnh báo mức thường (kho đầy), thẻ đỏ là mức nguy (ổ hệ điều hành đầy — Proxmox không ghi được nhật ký và cấu hình, node dở sống dở chết). Mỗi thẻ có câu vì sao đáng lo, và dòng “từ vừa xong · giờ”. Nút Đánh dấu đã xem tắt quầng đỏ quanh số trên thanh bên nhưng không đóng cảnh báo — cảnh báo chỉ đóng khi số đo thật về dưới ngưỡng.

Lúc	Sự kiện thật trong lịch sử	Đọc thế nào
18/09 12:47 → 12:48	Kho local 35 %, ổ hệ điều hành 35 % — bật rồi hết	Kiểm thử có chủ ý (ngưỡng tạm 30 %). Webhook nhận đủ gói bật và hết.
18/09 23:33 → 23:37	CPU0 84 °C → về 71 °C	Trùng sao lưu đêm 23:30. Vượt mốc hạ xung 83 °C.
19/09 06:25 → 06:37	CPU0 82 °C, CPU1 80 °C → về 74 / 73 °C	Hai socket cùng nóng.
19/09 10:58 → 11:03 và 11:08 → 11:11	WP3_PVE1 không trả lời — hai lần, 6 và 4 phút	B43 không gọi được API Proxmox. Nguyên nhân chưa điều tra trong bản này.

LƯU Ý · SỬA .ENV XONG PHẢI UP -D, KHÔNG PHẢI RESTART

Sáu biến cảnh báo chỉ được đọc lúc tạo container. docker compose restart lotus_cloud giữ nguyên môi trường cũ; phải docker compose up -d lotus_cloud. Bấm Gửi tin thử để chắc kênh đã thông trước khi cần thật.

▸ Không gửi qua Zalo: đường “gửi như người thật” chỉ có thư viện không chính thức, B43 sẽ phải giữ cookie đăng nhập Zalo của một người thật trong khi chính nó có đường vào từ Internet.

▸ Vượt ngưỡng mà chưa kêu ngay là đúng: cần 2 lượt liên tiếp — 10–20 giây khi có người mở trang Hạ tầng, 1–2 phút khi không.

▸ Sao lưu hỏng trước lúc B43 khởi động thì cố ý không phát lại — khởi động lại container không làm dội về một loạt tin cũ.

Chương 16 — Chiến lược sao lưu

16.1 Ảnh chụp nhanh KHÁC bản sao lưu

Hình 16.1. Khác biệt cốt lõi trong một hình: ảnh chụp nhanh nằm TRONG khung nét đứt — cùng một ổ đĩa với máy; bản sao lưu đi RA NGOÀI khung, sang một thiết bị lưu trữ khác.

Hình 16.2. Hai công cụ trả lời hai câu hỏi khác nhau. Nhầm chúng là nguyên nhân mất dữ liệu phổ biến nhất khi vận hành ảo hoá.

	Ảnh chụp nhanh (Snapshot)	Bản sao lưu (VZDump)
Trả lời câu hỏi	“Tôi vừa làm hỏng cấu hình, quay lại được không?”	“Ổ đĩa / máy chủ hỏng, dựng lại được không?”
Dữ liệu nằm ở đâu	Cùng một ổ đĩa với máy đang chạy, dạng lớp vi sai	Một tệp .vma.zst độc lập trong một kho khác
Tốc độ tạo	Rất nhanh — chỉ ghi siêu dữ liệu	Vài phút, tuỳ dung lượng (đo thật: ổ 32 GB trên kho local, chế độ snapshot)
Chi phí đĩa	Chỉ phần khác biệt kể từ lúc chụp	Toàn bộ dữ liệu, đã nén zstd
Ổ nguồn hỏng	Mất cả máy lẫn mọi ảnh chụp	Vẫn dựng lại được
Có tuỳ chọn giữ RAM?	Có (#snState)	Có, qua chế độ chụp

NGUY HIỂM · BẢN SAO LƯU KHÔNG CHỨA ẢNH CHỤP NÀO

vzdump ghi thẳng trong log: “skip all snapshots, pending changes and special sections” và “after the restore we have no snapshots anymore”. Khôi phục xong, máy không còn một ảnh chụp nào. Đừng dùng bản sao lưu để “giữ lại lịch sử điểm phục hồi”.

16.2 Ma trận dữ liệu — cái gì nằm ở đâu, ai lo sao lưu

Tài sản	Nơi lưu gốc	Cách bảo vệ	Ai làm
Ổ đĩa máy ảo và container	vmstore / local-lvm trên pve-001	Tự động 23:30 mỗi đêm vào kho pbs, giữ 7 ngày · 4 tuần · 6 tháng (từ 11/09/2026). Vẫn sao lưu tay được qua trang Sao lưu	Proxmox + PBS tự chạy
Ổ chung share và ổ nhanh fast	/mnt/share/data, /mnt/fast/data trên pve-001	Ảnh chụp hardlink (share 6 giờ/lần, fast mỗi giờ), mở lại qua Previous Versions. Không vào PBS, và bản chụp nằm cùng ổ	Timer lotus-snap@ trên node
Điểm phục hồi ngắn hạn	Lớp vi sai cùng ổ	Snapshot trước mỗi thay đổi lớn	Người vận hành, tab Snapshot
Bản mẫu Golden Master	vmstore	VZDump + lớp bảo vệ của Proxmox (từ chối xoá khi còn máy con liên kết)	Tự động một phần
Dữ liệu riêng của B43 (/data)	Ổ Docker lotus_cloud_data trên HP1	Chứa khoá SSH, lineage.json, vgpu_choice.json, project_meta.json, metrics.db; từ 18/09 thêm totp.json, nhat_ky.jsonl, canh_bao.json, ngu_dong.json. Mất /data không làm hỏng máy ảo nào — chỉ mất phả hệ, lựa chọn, sổ Hoạt động và khoá 2FA (2FA tự tắt), hệ thống lùi về hành vi mặc định an toàn.	Sao lưu ổ Docker
Mã nguồn và cấu hình B43	Repo git trên HP1	Commit + đẩy lên git	Người phát triển
Tệp .env (chứa mật khẩu)	Cạnh docker-compose.yml	Không nằm trong git. Phải sao lưu riêng, cất chỗ an toàn.	Người quản trị

16.3 Ba việc nên làm thành thói quen

1. Trước mỗi thay đổi mạo hiểm (cài driver, nâng cấp hệ điều hành, đổi cấu hình mạng): tạo một snapshot có mô tả rõ ràng. Mất 10 giây, cứu được cả buổi.

2. Sau mỗi cột mốc đáng giữ (máy vừa cài xong và chạy ổn): tạo một bản sao lưu VZDump, ghi mô tả vào ô Ghi chú. Snapshot không cứu được bạn khi ổ hỏng.

3. Trước khi xoá bất cứ thứ gì: mở cây phả hệ xem thứ đó có ai đang tựa vào không. Con số “N máy đang tựa vào đĩa” là câu trả lời.

16.4 Từ 11/09/2026: Proxmox Backup Server và lịch tự động

Máy chủ sao lưu chạy trong CT 201 trên chính pve-001, lưu vào ổ 4 TB sdc. Mỗi đêm 23:30 Proxmox sao lưu mọi máy ảo và container vào đó; PBS tự cắt tỉa, thu gom rác và kiểm SHA-256 theo lịch riêng. Ba thói quen ở mục 16.3 vẫn nguyên giá trị — lịch tự động chụp lúc 23:30, không chụp đúng khoảnh khắc trước khi bạn cài driver.

LƯU Ý · PBS NẰM TRÊN CHÍNH NODE NÓ BẢO VỆ

Nó cứu được: xoá nhầm máy, hỏng hệ điều hành khách, cập nhật hỏng, mã độc trong máy ảo. Nó không cứu được: chết node, chết ổ sdc. Chi tiết từng loại dữ liệu, lịch, hạn giữ, và cách khôi phục ở Phụ lục G.5 – G.6.

Từ 18/09/2026 lịch 23:30 này nhìn thấy và sửa được ngay trên trang Sao lưu (mục 12.1), kèm dòng Lần sao lưu gần nhất và cột Hạn còn lại của từng bản. Sao lưu hỏng thì cảnh báo chủ động (mục 15.5) báo ra ngoài.

Chương 17 — Ba kịch bản phục hồi thảm hoạ

17.1 Kịch bản A — Khôi phục thành một máy MỚI (an toàn)

Dùng khi: máy hiện tại lỗi phần mềm nhưng vẫn đang chạy vài dịch vụ; bạn muốn dựng bản cũ ra một máy riêng để so sánh dữ liệu, mà không đụng gì tới máy đang chạy.

2. Kiểm tra dải cảnh báo trên cùng: nếu có kho đọc không được, xử lý việc đó trước — bản bạn cần có thể đang nằm trong kho ấy.

3. Tìm bản sao lưu, đọc cột Ghi chú để chắc là đúng bản, rồi bấm Khôi phục.

4. Trong cửa sổ: chọn “Khôi phục thành Máy ảo MỚI (an toàn — giữ nguyên máy hiện tại)”.

5. Chọn Nơi đặt ổ đĩa. Cân nhắc dung lượng trống của kho đích.

6. Bấm Khôi phục. B43 cấp một mã VMID mới và dựng máy độc lập.

7. Trước khi bật máy mới: vào tab Cài đặt → thẻ Địa chỉ MAC → bấm Ngẫu nhiên → Áp dụng, để tránh hai máy cùng MAC (xem cảnh báo ở mục 10.3).

LƯU Ý · VÌ SAO PHẢI ĐỔI MAC Ở BƯỚC 7

Bản sao lưu mang theo nguyên cấu hình cũ, gồm cả địa chỉ MAC. Hai máy cùng MAC trên một lớp 2 làm bảng MAC của switch nhảy loạn ⇒ cả hai mất mạng, không phải một. Thẻ MAC sẽ hiện huy hiệu đỏ “Trùng N máy” để bạn thấy trước khi bật.

17.2 Kịch bản B — Khôi phục GHI ĐÈ lên máy cũ

Dùng khi: máy nhiễm mã độc, hỏng phân vùng hệ điều hành không khởi động được, hoặc bạn chắc chắn muốn quay về đúng trạng thái của bản sao lưu.

NGUY HIỂM · ĐÂY LÀ THAO TÁC PHÁ HUỶ, KHÔNG HOÀN TÁC ĐƯỢC

Ghi đè sẽ XOÁ SẠCH toàn bộ máy hiện tại trên máy chủ rồi mới dựng lại từ bản sao lưu. Mọi thay đổi sinh ra sau thời điểm chụp bản sao lưu sẽ mất vĩnh viễn — kể cả những ảnh chụp nhanh bạn đã tạo, vì bản sao lưu không mang theo ảnh chụp nào.

1. Tự hỏi trước: có cách nào rẻ hơn không? Nếu vấn đề mới xảy ra và máy còn ảnh chụp gần đây, khôi phục snapshot nhanh hơn và mất ít dữ liệu hơn nhiều.

2. Nếu vẫn phải ghi đè: tạo một bản sao lưu MỚI của máy đang hỏng trước. Nghe nghịch lý, nhưng nó giữ lại đường lui nếu bản cũ hoá ra không phải cái bạn cần.

5. Chọn “Ghi đè lên chính #<vmid> (XOÁ máy hiện tại)”. Dải cảnh báo đỏ sẽ hiện ra — đọc hết dòng đó, nó ghi rõ thời điểm bản sao lưu và mốc dữ liệu sẽ mất.

7. Đợi tiến trình hoàn tất. Bấm ↻ Làm mới nếu bảng chưa cập nhật.

8. Bật máy, kiểm tra dịch vụ. Nhớ rằng máy vừa dựng lại không còn ảnh chụp nào.

17.3 Kịch bản C — Một node hỏng phần cứng

Dùng khi: máy chủ vật lý cháy nguồn, hỏng bo mạch, hoặc phải thay hẳn.

LƯU Ý · ĐIỀU KIỆN TIÊN QUYẾT MÀ BẠN PHẢI CHUẨN BỊ TỪ TRƯỚC

Kịch bản này chỉ chạy được nếu bản sao lưu không nằm trên chính node đã hỏng. Kho local là kho riêng của từng node — bản sao lưu để trong đó sẽ chết cùng node. Với dữ liệu quan trọng, đích đúng là kho NFS trên White NAS.

Lưu ý từ 11/09/2026: kho pbs cũng nằm trên chính node — ổ sdc của pve-001 — nên nó không đáp ứng điều kiện tiên quyết này, dù trang Sao lưu hiện nó như mọi kho khác.

1. Xác nhận node thật sự hỏng chứ không phải chỉ đang tắt: vào Hạ tầng, đọc dòng lý do dưới huy hiệu offline; thử Send Wake-on-LAN; thử ping địa chỉ LAN của node.

2. Nếu node hỏng thật, máy ảo trên đó không tự chuyển sang node kia — hai máy chủ chạy độc lập, không phải một cụm, nên không có cơ chế chuyển đổi dự phòng tự động.

3. Vào Sao lưu. Các bản nằm trên kho của node còn sống hoặc trên NAS vẫn hiện bình thường; bản nằm trên node đã hỏng sẽ nằm trong danh sách unavailable.

4. Với từng máy cần cứu: bấm Khôi phục → Máy ảo MỚI → chọn node còn sống làm đích.

5. Kiểm tra cấu hình vGPU trước khi bật. Node thay thế có thể không có card NVIDIA. Vào tab Cài đặt → ô Card đồ hoạ ảo → chọn Không dùng vGPU nếu node đích không có card tương ứng — nếu không, máy sẽ từ chối khởi động với lỗi thiết bị PCI.

7. Bật máy, kiểm tra dịch vụ, rồi cập nhật lại các bản ghi DNS / cấu hình trỏ tới máy đó.

GHI CHÚ · SAU KHI NODE ĐƯỢC SỬA XONG

Đừng bật cả hai bản của cùng một máy. Máy cũ trên node vừa sửa và máy mới vừa dựng có cùng MAC, cùng SMBIOS UUID, cùng tên Windows — bật cả hai là hai máy đánh nhau trên mạng và mọi phần mềm đọc dấu vân tay đều nhầm lẫn. Quyết định giữ bản nào, rồi xoá hoặc đổi định danh bản kia.

Chương 18 — Trông như lỗi mà KHÔNG phải lỗi

Chương này đặt trước chương sự cố vì một lý do thực dụng: phần lớn báo lỗi gửi về thuộc danh sách dưới đây. Đọc hết bảng này trước khi mở phiếu sự cố sẽ tiết kiệm rất nhiều thời gian cho cả người báo lẫn người sửa.

Hiện tượng	Đây là đúng thiết kế, vì…	Muốn chắc thì làm gì
Chip vGPU xám ngay khi mở bảng	Bảng vẽ ngay với trạng thái checking, luồng nền mới đi hỏi máy khách.	Chờ ≥ 12 giây, hoặc bấm ↻ Làm mới. Vẫn xám thì đọc trường vgpu.reason.
Cột Địa chỉ IP trống	Máy đang tắt, hoặc chưa cài dịch vụ qemu-guest-agent bên trong.	Xem ô hiện chữ “— (máy đang tắt)” hay để trống hẳn. Máy đang chạy mà trống ⇒ cài agent.
Ô Bộ nhớ đứng ở 100 %	Thiếu driver bong bóng virtio-balloon ⇒ mem mà Proxmox trả về là bộ nhớ tiến trình QEMU chiếm ở máy chủ, gần bằng đúng số RAM đã cấp.	Kiểm bằng: status/current không có trường freemem. Cài bộ virtio-win.
Ô Ổ đĩa hiện “—”	Không hỏi được bên trong máy khách. Thà không có số còn hơn có số sai.	Đọc dòng chú thích ngay dưới ô — nó nói rõ lý do.
Ô Mạng hiện “đang đo…”	Tốc độ phải tính bằng hiệu hai lần đọc, nên nhịp đầu tiên chưa có số. Hiện 0 sẽ nhìn y hệt “mạng đứng im”.	Chờ thêm một nhịp (5 giây).
Console màn hình đen	Máy đã nạp driver NVIDIA GRID ⇒ màn hình giả lập của QEMU ngừng được vẽ.	Vào máy bằng Remote Desktop. Console vẫn dùng được ở giai đoạn BIOS.
Bảng Droplets thiếu một máy	Đó là bản mẫu — bị lọc khỏi bảng từ 30/08/2026 sau hai lần bị xoá nhầm.	Xem nó ở trang Cấu trúc/bản mẫu.
Bấm xong mà số không đổi	Bộ đệm live: còn hạn (10–45 giây).	Bấm ↻ Làm mới — nút này xoá cả hai tầng đệm.
Node vừa bật vẫn hiện offline	Bộ ngắt mạch chỉ được mở lại bởi luồng nền, mỗi 20 giây.	Chờ tới 20 giây. Bấm Làm mới không rút ngắn được.
Bấm tắt máy chủ xong node vẫn online	Cố ý không ngắt mạch ngay, để nút Wake không hiện ra khi máy còn đang tắt dở.	Chờ; huy hiệu sẽ chuyển sang offline sau khi máy tắt hẳn.
Trang Sao lưu không đổi trong lúc đang sao lưu	GET /api/backups đọc nội dung kho, mà bản sao lưu chỉ có mặt ở đó khi đã ghi xong.	Nhìn dòng xanh có thanh tiến độ ở đầu bảng. Đừng bấm Sao lưu lần nữa — lệnh thứ hai sẽ bị trả 409.
Bảng kho lưu trữ: tổng không khớp đã dùng	Cấp phát mỏng, hoặc kho nằm chung phân vùng hệ điều hành.	Đọc câu giải thích trong bảng bóc tách; nó tương ứng reconcile.kind.
Xoá xong mà cây phả hệ giữ lại tới 47 giây	Bản đệm còn hạn cộng với luồng dò ngược qua SSH chưa chạy lại.	Bấm ↻ Làm mới.
Bấm Bật hai lần, lần hai vẫn trả thành công	Trả 200 kèm ghi chú “Máy ảo vốn đã chạy sẵn”.	Không phải lỗi.
Năm nút nguồn ở trang chi tiết không hỏi xác nhận	Cố ý — đây là trang chi tiết, người dùng đã chủ đích vào tận nơi. Trong bảng danh sách, menu Tắt ▾ chỉ hỏi lại với Cắt điện.	Không phải lỗi.
fe80::… hiện dưới nhãn LINK-LOCAL chứ không phải IPv6	Đó là địa chỉ link-local, không kết nối tới máy từ nơi khác được. Gọi nó là IPv6 mới là nói sai.	Không phải lỗi.
Vừa bật 2FA xong, đăng nhập bằng đúng mã đó bị từ chối	Mã dùng rồi là hết trong cùng bước 30 giây — chống phát lại.	Đợi mã kế tiếp (mục 15.3).
Sổ Hoạt động có dòng Đăng nhập — mật khẩu đúng, chờ mã 2FA mỗi lần mình đăng nhập	Đó là bước 1/2 khi 2FA bật (máy chủ trả 401 + need_totp). Không phải lần sai, không bị tính vào bộ đếm chống dò.	Không cần làm gì — dòng OK đi liền sau là của cùng lần đó (mục 15.4). Còn thấy Đăng nhập thất bại — Sai thì đó là mật khẩu hoặc mã sai thật.
Mất điện thoại, không vào được B43	Đúng — đó chính là việc của lớp thứ hai.	docker exec lotus_cloud rm /data/totp.json, có hiệu lực ngay (mục 15.3).
Vượt ngưỡng mà cảnh báo chưa kêu ngay	Phải thấy 2 lượt liên tiếp: 10–20 giây khi có người mở trang Hạ tầng, 1–2 phút khi không.	Chờ (mục 15.5).
Điền Telegram/Slack vào .env mà trang Cảnh báo vẫn ghi chưa	restart không nạp biến môi trường mới.	docker compose up -d lotus_cloud.
Bấm Đánh dấu đã xem mà cảnh báo vẫn còn	Nút đó chỉ tắt quầng “chưa xem”. Cảnh báo đóng khi số đo thật về dưới ngưỡng trừ trễ.	Xử lý nguyên nhân (mục 15.5).
Dòng Tạm dừng trong menu Tắt ▾ bị xám	Tính năng mặc định tắt ở mọi máy — bật là chiếm chỗ trên đĩa.	Tab Cài đặt → Tạm dừng (ngủ) → tick (mục 10.3).
Máy vừa Tạm dừng hiện Đang tạm dừng chứ không phải Đã tắt	Với Proxmox nó là stopped, nhưng phiên làm việc còn nguyên trên đĩa.	Bấm Chạy tiếp (mục 7.5).
Uptime của máy lớn hơn thời gian máy thật sự chạy	Uptime cộng dồn qua lần Tạm dừng; có dấu nhỏ cạnh số.	Rê chuột: chú giải ghi tiến trình thật mới chạy bao lâu.
Ô Droplets trên thẻ máy chủ ít hơn số hàng trong bảng	Ô đó chỉ đếm máy ảo QEMU (kể cả bản mẫu), không đếm container LXC.	Không phải lỗi (mục 11.1).
Bấm Xoá bản sao lưu trên kho pbs thì báo Lỗi 502	Cố ý: token ghi vào PBS không có quyền xoá — máy bị chiếm quyền cũng không xoá được bản sao lưu.	Xoá thẳng trong PBS theo đường chỉ trong thông báo (mục 12.1).
Tab Hằng tháng trống trong khi đã sao lưu cả tháng	Bản chốt tháng là bản cuối tháng; tháng đang chạy chưa có.	Chờ hết tháng (mục 12.1).

Chương 19 — Sổ tay sự cố

19.1 Ma trận tra nhanh

Mã	Hiện tượng	Mức	Nguyên nhân gốc	Xử lý ngay
ERR-01	Máy ảo không có IP	Thấp	Chưa cài dịch vụ qemu-guest-agent bên trong	Xem mục 19.2
ERR-02	Node báo offline	Cao	Node tắt, hoặc đứt VPN IPSec	Xem mục 19.3
ERR-03	Không chọn được cỡ vGPU mong muốn	Trung bình	Quy tắc cùng cỡ — card đang khoá ở cỡ khác	Xem mục 19.4
ERR-04	Bấm xong số liệu không đổi	Thấp	Bộ đệm còn hạn	Bấm ↻ Làm mới
ERR-05	Văng ra trang đăng nhập giữa chừng	Thấp	Cookie b43_session hết hạn, hoặc container vừa khởi động lại	Đăng nhập lại; trang tự đưa về đúng chỗ cũ
ERR-06	Console rớt ngay, mã 1006	Trung bình	Đang mở B43 qua HTTP	Mở lại bằng HTTPS; xem mục 19.5
ERR-07	Console chỉ hiện khung đen	Thấp	Máy đã nạp driver GRID của vGPU	Dùng Remote Desktop
ERR-08	Không thu nhỏ được ổ đĩa	Thấp	B43 chủ động cấm	Chỉ nới rộng được
ERR-09	Proxmox từ chối xoá bản mẫu	Trung bình	Còn máy con nhân bản liên kết đang tựa vào đĩa (base volume in use)	Xoá máy con trước, hoặc chuyển chúng sang nhân bản đầy đủ
ERR-10	Ảnh màn hình trả 409	Thấp	Máy khai vga: none / vga: serial0	Đúng thiết kế — dùng Console nối tiếp
ERR-11	Ảnh màn hình lỗi, thông báo rỗng	Trung bình	QEMU trên node dựng không có libpng	Đã xử lý: tự lùi sang chụp PPM rồi đổi sang PNG
ERR-12	Gắn vGPU xong, trong máy không thấy card	Trung bình	Chưa tắt rồi bật lại — reboot không đủ	Xem mục 19.4
ERR-13	400 Parameter verification failed	Trung bình	Chuỗi hostpci0 sai dạng (thiếu mdev=)	Đã gom về một hàm chuẩn hoá. Đọc trường errors, không đọc message
ERR-14	Sao lưu lần hai trả 409	Thấp	Đã có một vzdump đang chạy cho cùng máy đó	Đây là cái phanh. Chờ lệnh đầu xong
ERR-15	Máy không khởi động, lỗi +pveN	Trung bình	Bản mẫu ghim phiên bản phần cứng ảo cao hơn mức node hỗ trợ	B43 tự gỡ ghim rồi bật lại, kèm thông báo
ERR-16	Dải băng đỏ No-Auth ở đầu trang	Cảnh báo an ninh	Chưa đặt B43_AUTH_PASSWORD	Khai mật khẩu trong .env rồi docker compose up -d lotus_cloud
ERR-17	Driver vGPU chạy nhưng chưa cấp phép	Cao	Máy khách chưa xin được giấy phép từ máy cấp phép	Sau ~20 phút card sẽ tụt hiệu năng mà không báo lỗi. Xem mục 19.6
ERR-18	Trang Cấu hình máy chủ chết lặng	Trung bình	Lỗi JavaScript: điều kiện vẽ khác điều kiện gắn sự kiện (chỉ lộ ra ở node Intel)	Đã sửa. Khi kiểm thử phải kiểm cả hai node

19.2 ERR-01 — Máy ảo không hiển thị địa chỉ IP

1. Kiểm tra máy có đang chạy không. Máy tắt thì cột IP trống là đúng.

2. Vào tab Cài đặt, xem ô Bật QEMU Guest Agent (#stAg) đã tích chưa. Lưu ý: tích ô này mới chỉ tạo cổng phía máy chủ.

3. Vào bên trong máy khách (qua Console hoặc SSH) và cài dịch vụ agent:

# Debian / Ubuntu

apt update && apt install -y qemu-guest-agent

systemctl enable --now qemu-guest-agent

# Windows: gan bo virtio-win roi chay

# virtio-win-gt-x64.msi (hoac qemu-ga-x86_64.msi)

1. Nếu vừa mới tích ô #stAg: phải tắt rồi bật lại máy để QEMU dựng cổng virtio.

3. Vẫn không hiện: kiểm bằng lệnh dưới đây trên HP1 — nếu nó trả “QEMU guest agent is not running” thì dịch vụ bên trong chưa chạy thật.

curl -s -b cookie.txt \

http://127.0.0.1:20430/api/droplets/pve-wp2-02/103/network | python3 -m json.tool

LƯU Ý · ẢNH ĐÁM MÂY GENERICCLOUD KHÔNG KÈM SẴN AGENT

Ảnh Debian/Ubuntu genericcloud không cài sẵn qemu-guest-agent. B43 xử lý bằng cách nhét một đoạn cloud-init cài sẵn — việc này cần kho lưu trữ bật kiểu nội dung snippets, mà Proxmox không bật sẵn. Hàm _ensure_snippets_enabled() tự thêm (thao tác thêm, giữ nguyên các kiểu cũ).

19.3 ERR-02 — Node báo offline

1. Đọc dòng lý do ngay dưới huy hiệu offline trên trang Hạ tầng. Nó phân biệt được “No route to host” (máy tắt hoặc đứt mạng) với các lỗi khác.

2. Từ HP1, thử ping bộ định tuyến của WP2 (172.16.20.1). Không thông ⇒ vấn đề là VPN IPSec, không phải máy chủ. Kiểm tra ER605 (giao diện web cổng 1024).

3. Ping được router mà không ping được .101/.102 ⇒ máy chủ đang tắt nguồn.

4. Trên trang Hạ tầng, bấm Send Wake-on-LAN. Gói đi qua node còn sống làm trạm chuyển tiếp — nếu cả hai node cùng tắt thì nút này vô tác dụng.

6. Huy hiệu sẽ tự chuyển sang online. Có thể chậm thêm tới 20 giây vì bộ ngắt mạch chỉ được mở lại bởi luồng nền dò.

19.4 ERR-03 / ERR-12 — Vấn đề với vGPU

Không chọn được cỡ vGPU mong muốn

1. Đọc dòng chú thích dưới ô chọn vGPU. Nó nói đích danh những máy đang giữ card và cỡ card đang khoá.

2. Nhớ quy tắc: khoá theo cỡ, không theo mã hồ sơ. Cỡ 1 GB thì 1A/1B/1Q đều chọn được; cỡ 2 GB thì không.

3. Muốn đổi sang cỡ khác: tắt hết các máy đang giữ card, rồi vào Cấu hình máy chủ đổi cách chia và bấm Áp dụng cấu hình.

4. Nếu chỉ muốn tạm bỏ giới hạn của trang Tạo Droplet mà không đổi phần cứng: bấm Bỏ chốt ở khối Hồ sơ chuẩn cho trang Tạo Droplet.

Gắn vGPU xong nhưng trong máy không thấy card

1. Tắt hẳn máy rồi bật lại. reboot từ bên trong hệ điều hành là chưa đủ — cấu hình hostpci0 chỉ được đọc lúc QEMU dựng tiến trình.

2. Kiểm chứng bằng GET /nodes/{node}/qemu/{vmid}/pending trên máy chủ: còn khoá pending nghĩa là máy đang chạy chưa nhận thay đổi.

3. Máy đã thấy thiết bị thì vào tab Tổng quan → khối Card đồ hoạ → bấm Cài driver vGPU. Quá trình mất 3–8 phút và chạy tiếp kể cả khi bạn đóng trang.

19.5 ERR-06 — Console rớt kết nối, mã 1006

Triệu chứng: cửa sổ console mở ra, hiện dòng “noVNC requires a secure context (TLS). Expect crashes!”, rồi mất kết nối ngay sau lời chào RFB.

1. Nguyên nhân gần như luôn là đang mở B43 qua HTTP. Phần xác thực VNC cần crypto.subtle, thứ chỉ tồn tại trong ngữ cảnh bảo mật.

2. Mở lại B43 bằng địa chỉ HTTPS chính thức (https://b43.lotuscloud.lotus1104.synology.me/).

3. Trong LAN mà tên miền không phân giải vào được (hairpin NAT): thêm dòng 172.16.10.220 b43.lotuscloud.lotus1104.synology.me vào tệp hosts của máy bạn. Chứng chỉ vẫn hợp lệ vì nó gắn với tên, không phải IP.

4. Đặt biến B43_PUBLIC_HTTPS_URL trong .env để nút Mở console tự nhảy sang HTTPS.

GHI CHÚ · CÁCH PHÂN BIỆT LỖI PROXY VỚI LỖI NGỮ CẢNH BẢO MẬT

Nếu nghi ngờ chính đường chuyển tiếp hỏng, hãy thử ngoài trình duyệt: chạy một trình khách WebSocket bằng Python từ trong container. Bắt tay xong và nhận đúng b'RFB 003.008\n' nghĩa là proxy hoàn toàn tốt, vấn đề nằm ở ngữ cảnh bảo mật của trình duyệt.

19.6 ERR-17 — Driver chạy nhưng chưa được cấp phép

NGUY HIỂM · ĐÂY LÀ SỰ CỐ NGUY HIỂM NHẤT VÌ NÓ IM LẶNG

Card chạy bình thường khoảng 20 phút rồi bị hạ hiệu năng xuống vài khung hình một giây. Không có thông báo lỗi nào — người dùng chỉ thấy máy “tự nhiên chậm dần”, và thường đi tìm nguyên nhân ở CPU, ở mạng, ở phần mềm.

Dấu hiệu trên B43: chip vGPU xanh nhưng viền đứt (.vg-ok.vg-nolic), và hộp trạng thái ở khối Card đồ hoạ ghi Unlicensed.

1. Bấm Kiểm tra driver để lấy trạng thái mới nhất, đọc dòng License Status.

2. Phân biệt hai trạng thái: Unlicensed (Unrestricted) nghĩa là chưa tới hạn bị siết, còn Unlicensed (Restricted) nghĩa là đã bị siết rồi.

3. Kiểm tra đồng hồ của máy khách trước tiên. Đây là thủ phạm đã gặp trong thực tế: máy Windows để múi giờ Pacific khiến giờ UTC lệch 14 tiếng, và máy cấp phép từ chối cấp — trong khi giờ hiển thị trên màn hình vẫn đúng, nên rất khó ngờ.

4. Kiểm tra máy khách có với tới máy cấp phép không: https://172.16.10.220:20440.

5. Bấm Cài lại driver — nút này làm lại cả bước xin giấy phép.

LƯU Ý · MỘT SỰ CỐ NỮA CỦA DRIVER GRID ĐÃ GẶP TRÊN CARD ĐÃ VÁ

Bản driver khách 553.74 đã từng treo cứng máy khách trên GTX 1660 Ti chạy vgpu_unlock, đúng ở bước xin giấy phép từ máy cấp phép. Cách cứu: tắt cứng máy ảo rồi gỡ hostpci0 ra khỏi cấu hình trước khi bật lại — máy sẽ lên bình thường mà không có card.

Chương 20 — Tám bài thực hành

GHI CHÚ · HƯỚNG DẪN CHO GIẢNG VIÊN

Mỗi bài gồm bốn phần: mục tiêu, các bước, tiêu chí đạt và câu hỏi kiểm tra hiểu. Câu hỏi kiểm tra quan trọng ngang các bước — học viên làm đúng thao tác mà không hiểu vì sao thì lần sau gặp biến thể sẽ hỏng.

▸ Bài 1–3 làm được trên tài nguyên có sẵn, không cần chuẩn bị gì thêm.

▸ Bài 4–5 có thao tác phá huỷ có kiểm soát — chỉ làm trên máy thực hành, không làm trên máy của người khác.

▸ Bài 6–7 đòi quyền quản trị hạ tầng, nên dành cho lớp nâng cao.

▸ Bài 8 (thêm 19/09/2026) đòi quyền sửa .env trên HP1 và một kênh Slack thử.

Bài 1 — Tạo một Droplet Linux từ ảnh đám mây

Mục tiêu: tạo được một máy Debian chạy được, đăng nhập bằng khoá SSH, và giải thích được vì sao ảnh đám mây khác đĩa ISO.

1. Vào trang SSH Keys → Thêm khoá. Trên máy cá nhân chạy ssh-keygen -t ed25519, rồi cat ~/.ssh/id_ed25519.pub và dán cả dòng vào ô nội dung.

3. Bước 1: chọn node đang trực tuyến. Quan sát node đang tắt bị làm mờ và khoá bấm.

4. Bước 2: giữ nguyên tab Hệ điều hành, chọn Debian 13 (Trixie).

5. Bước 3: chọn gói Nhỏ (2 vCPU / 2 GB). Quan sát thước đo tải máy chủ thay đổi.

6. Bước 4: chọn kho vmstore, để dung lượng 20 GB. Quan sát dòng “còn trống”.

9. Bước 7: đặt tên lab01-debian, chọn dự án, đọc kỹ bảng Tóm tắt bên phải, rồi bấm Tạo Droplet.

10. Quay về bảng Droplets, chờ máy chuyển sang Đang chạy và cột Địa chỉ IP hiện lên.

11. Từ máy cá nhân: ssh root@<IP> — phải vào được không hỏi mật khẩu.

Tiêu chí đạt	Cách chứng minh
Máy chạy	Cột Trạng thái hiện Đang chạy
Guest Agent hoạt động	Cột Địa chỉ IP có số, không phải để trống
Khoá SSH được nhúng đúng	ssh root@<IP> vào thẳng, không hỏi mật khẩu
Ổ đĩa đọc được từ bên trong	Ô Ổ đĩa ở trang chi tiết có số phần trăm, không phải “—”

MẸO · CÂU HỎI KIỂM TRA HIỂU

(a) Vì sao ảnh đám mây khởi động nhanh hơn nhiều so với cài từ ISO? (b) Máy vừa tạo có địa chỉ IP hiện lên ngay — nhờ đâu? (c) Nếu cột IP để trống thì việc đầu tiên cần kiểm là gì?

▸ (a) Ảnh đám mây đã cài sẵn một hệ điều hành tối giản; máy chủ chỉ cần chép đĩa vào kho rồi nạp cloud-init lúc khởi động lần đầu. Còn ISO là bắt đầu từ con số không: phân vùng, chép tệp, cấu hình.

▸ (b) Nhờ đoạn cloud-init mà B43 nhét vào đã cài sẵn qemu-guest-agent — ảnh genericcloud gốc không kèm gói này.

▸ (c) Kiểm dịch vụ agent bên trong máy khách, không phải kiểm cờ agent: 1 ở máy chủ. Hai thứ khác nhau.

Bài 2 — Đọc đúng sáu ô số liệu

Mục tiêu: phân biệt được con số máy chủ đo được và con số phải hỏi vào trong máy khách, và biết khi nào một con số là vô nghĩa.

2. Ghi lại giá trị của cả sáu ô: CPU · Bộ nhớ · Ổ đĩa · Mạng · GPU · Uptime.

3. Mở trang chi tiết của máy #103 vpn-pc-01 (máy Windows có vGPU) và ghi lại tương tự.

4. So sánh ô Bộ nhớ của hai máy. Máy Windows có thể đứng ở gần 100 %.

6. Bấm ↻ Làm mới rồi quan sát ô Mạng: nhịp đầu tiên hiện “đang đo…”.

7. Gạt khối biểu đồ sang khung 24 giờ, rê chuột ngang đồ thị và quan sát vạch dóng đồng bộ trên cả bốn đồ thị.

MẸO · CÂU HỎI KIỂM TRA HIỂU

(a) Ô nào trong sáu ô là con số máy chủ không thể tự biết? (b) Vì sao ô Bộ nhớ của máy Windows đứng gần 100 %? Dấu hiệu nào xác nhận? (c) Số liệu GPU đến từ đâu, và vì sao nó là thứ duy nhất B43 tự lưu?

▸ (a) Ổ đĩa (phải hỏi agent/get-fsinfo) và GPU (Proxmox không có).

▸ (b) Thiếu số liệu bong bóng ⇒ mem trở thành bộ nhớ tiến trình QEMU chiếm ở máy chủ. Dấu hiệu chắc chắn: mem > maxmem, hoặc thiếu trường freemem.

▸ (c) Lấy mẫu nvidia-smi vgpu -q mỗi 15 giây, lưu vào /data/metrics.db. CPU/bộ nhớ/mạng thì Proxmox đã giữ sẵn 24 giờ trong RRD — chép lại chỉ tạo bản sao lệch nhịp.

Bài 3 — Snapshot, phá hoại có kiểm soát, rồi khôi phục

Mục tiêu: hình thành phản xạ chụp điểm phục hồi trước khi làm việc mạo hiểm, và hiểu giới hạn của snapshot.

LƯU Ý · PHẠM VI BÀI THỰC HÀNH

Chỉ làm trên máy lab01-debian của chính bạn. Bài này có thao tác phá hoại có kiểm soát.

1. Vào tab Snapshot → Tạo snapshot. Tên truoc-khi-pha, mô tả “Điểm an toàn trước bài thực hành 3”. Không tích Lưu cả trạng thái RAM.

5. Vào tab Snapshot → bấm Khôi phục trên điểm truoc-khi-pha.

7. Kiểm tra tệp /root/moc.txt: nó đã biến mất, vì được tạo sau thời điểm chụp.

MẸO · CÂU HỎI KIỂM TRA HIỂU

(a) Vì sao /root/moc.txt biến mất? (b) Nếu ổ đĩa vật lý chứa máy này hỏng, snapshot có cứu được không? (c) Bản sao lưu vừa tạo có mang theo snapshot không?

▸ (a) Khôi phục snapshot đưa toàn bộ ổ đĩa về đúng trạng thái lúc chụp — mọi thay đổi sau đó đều mất, không riêng phần bị hỏng.

▸ (b) Không. Lớp vi sai nằm cùng ổ với máy. Ổ hỏng là mất cả hai.

▸ (c) Không. vzdump ghi rõ trong log là bỏ qua mọi snapshot.

Bài 4 — Nới rộng ổ đĩa nóng

Mục tiêu: mở rộng ổ đĩa cho một máy đang phục vụ, và hiểu vì sao thao tác ngược lại bị cấm.

1. Trên máy lab01-debian đang chạy, SSH vào và chạy df -h / — ghi lại dung lượng.

2. Vào tab Cài đặt → khối Cấu hình phần cứng → thanh trượt Dung lượng ổ đĩa.

3. Thử kéo thanh trượt về bên trái. Quan sát: nó không xuống dưới mức hiện tại.

5. Trong máy khách, chạy lại df -h /. Với ảnh đám mây, cloud-init thường tự nới phân vùng lúc khởi động; nếu chưa, dùng growpart rồi resize2fs.

MẸO · CÂU HỎI KIỂM TRA HIỂU

(a) Vì sao B43 cấm thu nhỏ ổ đĩa, trong khi Proxmox về mặt kỹ thuật làm được? (b) Nếu bạn tăng vCPU và RAM ở cùng khối này, thay đổi có hiệu lực khi nào?

▸ (a) Vì thu nhỏ đòi thu hệ thống tệp bên trong máy khách trước, và không có cách nào để giao diện bảo đảm bước đó đã làm đúng. Sai thứ tự là mất sạch dữ liệu.

▸ (b) Chỉ sau lần tắt rồi bật kế tiếp — trừ khi tích ô tắt máy trước khi lưu. Dòng cảnh báo vàng ở đầu khối nói rõ điều này.

Bài 5 — Gán vGPU và cài driver bằng một nút

Mục tiêu: cấp card đồ hoạ cho máy ảo và đọc đúng trạng thái driver bên trong máy khách.

LƯU Ý · CẦN MỘT CHỖ TRỐNG TRÊN CARD

Kiểm trước ở trang Cấu hình máy chủ: khối cảnh báo vàng liệt kê những máy đang giữ card. Card đã đầy thì bài này phải chờ hoặc phải tắt bớt một máy.

2. Tab Cài đặt → ô Card đồ hoạ ảo (vGPU). Đọc kỹ dòng chú thích: nó nói cỡ đang khoá và còn mấy chỗ.

4. Bật máy lên (đây là bước bắt buộc — reboot không đủ).

5. Tab Tổng quan → khối Card đồ hoạ. Ban đầu hộp trạng thái sẽ màu cam: đã gắn card mà chưa có driver.

6. Bấm Cài driver vGPU. Theo dõi nhật ký tiến trình. Mất 3–8 phút.

8. Quay lại bảng Droplets, chờ ≥ 12 giây rồi quan sát màu chip vGPU.

Kết quả	Nghĩa	Việc tiếp theo
Xanh lá, viền liền	Driver chạy, đã cấp phép	Xong
Xanh lá, viền đứt	Driver chạy, chưa cấp phép	Phải xử lý. Sau ~20 phút card sẽ tụt hiệu năng mà không báo lỗi. Xem mục 19.6
Cam	Đã gắn card, chưa có driver	Bấm Cài driver vGPU
Xám sau khi đã chờ đủ	Chưa hỏi được	Đọc trường reason; kiểm agent trong máy khách

MẸO · CÂU HỎI KIỂM TRA HIỂU

(a) Vì sao gắn vGPU xong phải tắt rồi bật, reboot không đủ? (b) Vì sao chip xanh viền đứt lại nguy hiểm hơn chip cam? (c) Nút Cài driver gửi lệnh vào máy khách bằng đường nào, và vì sao không dùng SSH?

▸ (a) Cấu hình hostpci0 chỉ được đọc lúc QEMU dựng tiến trình. Máy đang chạy thì bên trong không hề có thiết bị nào.

▸ (b) Chip cam nói thẳng là chưa dùng được, ai cũng thấy. Chip viền đứt thì trông như đã xong — hỏng chỉ lộ ra sau 20 phút, dưới dạng “máy tự nhiên chậm”.

▸ (c) Qua QEMU Guest Agent, kênh virtio giữa máy chủ ảo hoá và máy khách. Dùng SSH sẽ buộc B43 phải giữ mật khẩu hoặc khoá của từng máy khách — đổi chút tiện lợi lấy một kho chìa khoá tập trung là món hời rất tệ.

Bài 6 — Bản mẫu và cây phả hệ

Mục tiêu: hiểu nhân bản liên kết, đọc được cây phả hệ, và biết vì sao bản mẫu được bảo vệ đặc biệt.

1. Vào Cấu trúc/bản mẫu, đọc thẻ bản mẫu hiện có: mã, node, dung lượng, ghi chú, và con số “N máy đang tựa vào đĩa”.

4. Tìm một hàng có nhãn liên kết và một hàng có nhãn đầy đủ. Ghi lại khác biệt.

5. Bật ô tick hiện ảnh chụp. Quan sát ảnh chụp thành hàng con và nhãn “máy đang đứng ở đây”.

6. Dùng ô lọc theo dự án. Quan sát bản mẫu vẫn hiện (làm giàn) nhưng được làm mờ.

7. Chọn một hàng và quan sát thanh thao tác đổi theo loại hàng đã chọn.

8. Không bấm nút xoá. Chỉ quan sát rằng nó đòi gõ lại mật khẩu.

MẸO · CÂU HỎI KIỂM TRA HIỂU

(a) Nhân bản liên kết tốn bao nhiêu dung lượng lúc mới tạo, và điều đó kéo theo hệ quả gì cho bản mẫu gốc? (b) Vì sao có hai kiểu nét đường? (c) “Máy mất gốc” là gì, máy đó còn dùng được không?

▸ (a) 0 GB — nó chỉ ghi phần khác biệt. Hệ quả có lợi: Proxmox từ chối xoá bản mẫu gốc khi còn máy con (base volume in use). Lớp bảo vệ này nằm trong Proxmox, không phụ thuộc giao diện.

▸ (b) Hai nguồn dữ liệu khác nhau. Nét liền = đo được bằng lvs -o origin (chính xác nhưng mất khi cha bị xoá). Nét đứt = ghi sổ trong lineage.json (bền, nhưng chỉ có với máy do chính B43 nhân bản).

▸ (c) Sổ có ghi nguồn gốc nhưng bản mẫu cha không còn trên máy chủ. Máy vẫn chạy bình thường, dữ liệu còn nguyên — chỉ là không nhân bản thêm từ cùng một gốc được nữa.

Bài 7 — Diễn tập phục hồi thảm hoạ

Mục tiêu: chạy trọn một kịch bản phục hồi thật, và đo thời gian.

NGUY HIỂM · BÀI NÀY CÓ THAO TÁC XOÁ MÁY

Chỉ làm trên máy thực hành của chính bạn. Đọc hết các bước trước khi bắt đầu.

1. Tạo một bản sao lưu VZDump cho lab01-debian. Ghi mô tả rõ. Bấm đồng hồ.

2. Trong lúc chờ, thử bấm Sao lưu ngay lần thứ hai cho cùng máy đó — quan sát hệ thống trả 409 kèm giờ bắt đầu của lệnh đang chạy.

6. Vào Sao lưu, tìm bản vừa tạo, bấm Khôi phục → Máy ảo MỚI.

8. Trước khi bật: vào tab Cài đặt → thẻ Địa chỉ MAC → Ngẫu nhiên → Áp dụng.

10. Ghi vào biên bản: thời gian sao lưu, dung lượng, thời gian khôi phục, và những gì đã mất so với trước khi xoá.

MẸO · CÂU HỎI KIỂM TRA HIỂU

(a) Vì sao hệ thống trả 409 thay vì xếp hàng lệnh sao lưu thứ hai? (b) Máy khôi phục có còn snapshot không? (c) Vì sao phải đổi MAC trước khi bật? (d) Nếu bản sao lưu nằm trên kho local của node đã hỏng thì sao?

▸ (a) Hai vzdump chồng nhau cùng cày một ổ đĩa làm cả hai chậm gần gấp đôi. Đây là cái phanh, không phải sự bất tiện.

▸ (b) Không. Bản sao lưu không mang theo snapshot nào.

▸ (c) Bản sao lưu mang nguyên cấu hình cũ, gồm cả MAC. Nếu máy cũ (hoặc một bản khôi phục khác) cùng chạy thì cả hai mất mạng.

▸ (d) Mất luôn. Kho local là kho riêng của từng node. Đó là lý do bản sao lưu quan trọng phải đẩy sang NAS.

Bài 8 — Ba lớp bảo vệ mới: 2FA, cảnh báo ra Slack, lịch sao lưu

Mục tiêu: tự tay thấy ba lớp thêm ngày 18/09/2026 hoạt động — và thấy được dấu vết mỗi việc mình vừa làm trong sổ Hoạt động.

NGUY HIỂM · LÀM TRÊN MỘT BẢN B43 THỬ, HOẶC GIỮ SẴN ĐƯỜNG CỨU

Bước 1 có thể khoá chính bạn ra ngoài nếu làm dở. Trước khi bắt đầu, chắc chắn bạn chạy được docker exec lotus_cloud rm /data/totp.json trên HP1. Không hạ ngưỡng cảnh báo trên hệ thống thật mà quên trả lại.

1. 2FA. Bấm tên người dùng ở chân thanh bên → Bật → quét QR bằng ứng dụng trên điện thoại → gõ mã → Xác nhận. Đăng xuất, đăng nhập lại: quan sát ô Mã xác thực chỉ hiện sau khi mật khẩu đúng.

2. Thử gõ lại đúng mã vừa dùng để xác nhận trong vòng 30 giây — quan sát bị từ chối. Đợi mã kế tiếp rồi vào.

3. Sổ Hoạt động. Mở Hoạt động: tìm hai dòng của lần đăng nhập vừa rồi (một chờ mã 2FA, một OK) và dòng 2FA: BẬT.

4. Slack. Tạo Incoming Webhook cho một kênh thử (api.slack.com → Your Apps → Incoming Webhooks), dán URL vào B43_SLACK_WEBHOOK trong .env, chạy docker compose up -d lotus_cloud.

5. Trang Cảnh báo: hàng Slack đổi sang đã cấu hình. Bấm Gửi tin thử — tin tới kênh trong vài giây.

6. Hạ tạm B43_ALERT_KHO xuống dưới mức đầy hiện tại của kho local, up -d lần nữa, mở trang Hạ tầng và bấm đồng hồ. Ghi lại lúc thẻ cảnh báo xuất hiện, lúc tin Slack tới, và số đỏ trên thanh bên.

8. Lịch sao lưu. Trang Sao lưu → Thêm lịch… → chọn Chủ nhật 01:00, phạm vi Chỉ những máy chọn → một máy thực hành → Tạo lịch. Kiểm cột Lần chạy tới. Rồi Xoá lịch thử đó.

Tiêu chí đạt	Kiểm bằng
Đăng nhập đòi mã; mã dùng rồi bị từ chối	Bước 1–2
Tìm được đủ dấu vết trong sổ Hoạt động	Bước 3 — cột Ai, Từ, Kết quả
Tin thử và cả cặp bật / hết tới kênh Slack	Bước 5–7
Thời gian từ lúc vượt ngưỡng tới lúc có tin nằm trong khoảng 10–20 giây (đang mở trang Hạ tầng)	Bước 6 — hai lượt nhịp chung
Lịch thử có Lần chạy tới là Chủ nhật 01:00 kế tiếp, xoá sạch sau bài	Bước 8

MẸO · CÂU HỎI KIỂM TRA HIỂU

(a) Vì sao sửa .env xong restart là không đủ? (b) Vì sao cảnh báo không kêu ngay lượt đầu tiên vượt ngưỡng? (c) Vì sao sổ Hoạt động cần tồn tại khi Proxmox đã có nhật ký tác vụ? (d) Vì sao nút Xoá bản sao lưu trên kho pbs báo lỗi, và đó có phải lỗi không?

▸ (a) Biến môi trường chỉ được đọc khi container được tạo; restart giữ môi trường cũ.

▸ (b) Luật 2 lượt liên tiếp — một mẫu nhiễu trong 10 giây không đáng một tin nhắn.

▸ (c) Proxmox chỉ thấy root@pam — mọi việc từ B43 đều mang tên đó. Cột Ai chỉ có ở sổ của B43.

▸ (d) Không phải lỗi. Token ghi vào PBS cố ý không có quyền xoá: một máy chủ bị chiếm quyền cũng không xoá được bản sao lưu của chính nó.

Phụ lục A — Ổ cứng, phân vùng và bố cục lưu trữ — biên bản khảo sát

GHI CHÚ · VÌ SAO PHỤ LỤC NÀY TỒN TẠI

Toàn bộ phần này là biên bản của những cuộc khảo sát và tranh luận có thật trên pve-wp2-02, giữ lại nguyên số đo và nguyên cả những kết luận đã sai cùng lý do vì sao chúng sai. Chương 4 chỉ nêu kết quả; ở đây là đường đi tới kết quả đó — phần có giá trị đào tạo lớn hơn.

A.1 Bố cục vật lý thật (khảo sát 29/08/2026)

Kho	Kiểu	Nằm trên phần cứng nào
local / local-lvm	dir / lvmthin	NVMe Samsung 970 EVO 250 GB, nhóm ổ luận lý pve
vmstore	lvmthin	Nhóm vmdata = sda (Samsung 850 EVO 233 GB) + sdb (Micron 1100 238 GB)
shared (đã gỡ bỏ)	dir /mnt/shared	Đúng ra là HDD WD10JPVT 1 TB (sdc1) — xem A.2 và A.4

Đối chiếu với trạng thái hiện tại (07/09/2026): kho shared không còn tồn tại. Biến B43_STORAGE_MEDIA trong .env vẫn còn dòng ánh xạ "shared":"hdd", nhưng nó vô hại — đó chỉ là bảng tra để hiện chip Loại ổ.

A.2 Bẫy 1 — kho kiểu dir ghi nhầm xuống ổ hệ thống, TRONG IM LẶNG

/mnt/shared không gắn kết được (sector hỏng khiến fsck lúc khởi động thất bại; tuỳ chọn nofail khiến máy vẫn khởi động êm ru). Nhưng Proxmox vẫn báo kho shared active — vì nó chỉ kiểm rằng có một thư mục ghi được ở đường dẫn đó.

NGUY HIỂM · HẬU QUẢ: MỌI THỨ ĐỔ VÀO “Ổ 1 TB” THỰC RA RƠI XUỐNG Ổ HỆ THỐNG 250 GB

Và không có một dòng cảnh báo nào. Dấu hiệu nhận ra: hai kho local và shared báo dung lượng y hệt nhau — vì chúng thực chất là cùng một phân vùng.

▸ Cách chặn đúng nhất là tuỳ chọn is_mountpoint 1 trong /etc/pve/storage.cfg: Proxmox sẽ đánh dấu kho inactive nếu đường dẫn không phải một điểm gắn kết thật.

▸ B43 cũng có GET /api/nodes/{node}/storage-health để cảnh báo tình huống này.

A.3 Bẫy 2 — vmstore KHÔNG có dư thừa nào

Đây là điều quan trọng nhất của cả phụ lục, và cũng là điều dễ hiểu sai nhất: nhìn thấy hai ổ SSD gộp lại thành một kho 466 GB, rất nhiều người mặc định rằng “chắc là RAID”.

NGUY HIỂM · VMDATA LÀ GHÉP NỐI TIẾP (LINEAR CONCAT), KHÔNG PHẢI RAID0 VÀ KHÔNG PHẢI GƯƠNG

Bằng chứng: lvs cho #Seg 2, #Str 1 — hai đoạn, mỗi đoạn một dải. Và metadata của thin pool (vmstore_tmeta) nằm trên /dev/sda.

▸ ⇒ Hỏng bất kỳ ổ nào trong hai ổ là mất TOÀN BỘ pool, kể cả phần dữ liệu còn nguyên vẹn trên ổ kia.

▸ ⇒ Việc chuyển sang cấu hình gương đã được quyết định, nhưng hoãn lại vì bản mẫu win10-wp2-gpu vừa được tạo lên đó.

▸ ⇒ Cho tới khi chuyển xong: bản sao lưu quan trọng không được để trên vmstore.

A.4 Bài học lớn nhất: lượt GHI sạch KHÔNG chứng minh được gì

Kế hoạch ban đầu để kiểm ổ cơ 1 TB là: ghi rồi đọc 100 lần vào đúng sector từng hỏng (khối 4K số 231735552). Nếu đạt 100/100 thì kết luận “sector hỏng mềm, mặt đĩa còn tốt” và dựng ZFS lên đó.

NGUY HIỂM · KẾT LUẬN SỚM ĐÓ SAI HOÀN TOÀN — VÀ ĐÂY LÀ PHẦN ĐÁNG HỌC NHẤT

▸ Ổ nhận dữ liệu vào bộ đệm rồi báo thành công. Hỏng chỉ lộ ra ở lượt ĐỌC LẠI. Kết luận “mặt đĩa còn tốt” khi mới có kết quả lượt ghi là sai về nguyên tắc.

▸ Sector hỏng GỐC không nằm trong 32 khối hỏng mới. Nếu chỉ kiểm 100 lần vào đúng chỗ cũ theo kế hoạch, kết quả sẽ là 100/100 đạt — và cho một niềm tin sai hoàn toàn. Chỉ quét toàn mặt đĩa mới ra sự thật.

▸ Bắt buộc O_DIRECT cả hai chiều. Không có nó thì lượt đọc chỉ lấy lại từ bộ đệm trang của nhân, bài kiểm luôn “đạt” mà chưa hề chạm đĩa.

Chỉ số	Giá trị	Đọc thế nào
Khối hỏng	32	Dồn vào một dải liền 87,0 % → 95,5 % chiều dài ổ ⇒ hư hỏng vật lý khu trú, không rải rác
Current_Pending_Sector	1 → 0 → 37	Số sector đang chờ được ánh xạ lại
Reallocated_Sector_Ct	0	Ổ KHÔNG tự ánh xạ lại được — đây là dấu hiệu xấu
Raw_Read_Error_Rate	85 → 415	Tăng gần 5 lần trong một lượt quét
Lỗi nhân hệ điều hành	94	Ghi trong dmesg
UDMA_CRC_Error_Count	0	Cáp tốt — loại trừ nguyên nhân kết nối
Spin_Retry_Count	0	Mô-tơ tốt — loại trừ nguyên nhân cơ khí
smartctl -H	PASSED	Dòng này vô dụng. Ổ hỏng 32 khối vẫn báo PASSED

LƯU Ý · BA CÂU ĐÁNG NHỚ RÚT RA TỪ VỤ NÀY

▸ smartctl -H báo PASSED không có nghĩa là ổ tốt. Phải đọc từng thuộc tính.

▸ Reallocated = 0 mà Pending tăng là tình huống xấu hơn Reallocated cao: ổ đã hết chỗ dự phòng hoặc không tự sửa được.

▸ Hư hỏng khu trú thành dải thường là mặt đĩa, không phải cáp hay mô-tơ — hai chỉ số UDMA_CRC và Spin_Retry loại trừ giúp bạn hai giả thuyết đó ngay.

Đã xử lý (tối 29/08/2026): gỡ kho (pvesm remove shared), xoá dòng fstab, xoá /mnt/shared. Ổ /dev/sdc nay trống trơn, không gắn kết, không ai dùng. Kế hoạch dựng ZFS trên ổ đó bị huỷ — không dựng hệ tập tin lên một ổ đã hỏng, dù ZFS có checksum tốt tới đâu.

A.5 Cuộc thảo luận về ZFS — và vì sao vẫn giữ kho kiểu dir

Trước khi biết ổ hỏng thật, phương án đã chốt cho ổ cơ 1 TB là ZFS. Lập luận vẫn còn nguyên giá trị cho lần thay ổ tiếp theo:

A.6 Cấp phát mỏng — đọc số cho đúng

Con số	Nghĩa thật	Sai lầm thường gặp
Cột Dung lượng của một ổ đĩa ảo	Dung lượng khai báo	Cộng cột này rồi so với “Đã dùng” của kho ⇒ luôn lệch
Đã dùng của kho lvmthin	Dung lượng thực chiếm	Tưởng thiếu chỗ vì nhìn tổng khai báo
Đã dùng của kho dir	Mức dùng của cả phân vùng, gồm cả hệ điều hành	Tưởng kho đầy vì Proxmox chiếm chỗ

NGUY HIỂM · RỦI RO RIÊNG CỦA THIN POOL: ĐẦY METADATA

Thin pool có hai thứ có thể đầy: vùng dữ liệu và vùng metadata. Metadata đầy thì pool chuyển sang chỉ đọc và mọi máy trên đó dừng ghi ngay lập tức. Snapshot là thứ ăn metadata nhanh nhất. Giữ nhiều snapshot lâu ngày trên lvmthin là con đường ngắn nhất tới sự cố này.

GHI CHÚ · BỐ CỤC Ở A.1 ĐÃ ĐƯỢC THAY HOÀN TOÀN NGÀY 11/09/2026

Phụ lục này là biên bản ngày 29/08/2026 và được giữ nguyên. Máy nay có hai ổ cơ mới (4 TB SMR và 500 GB CMR), một máy chủ sao lưu và một ổ chung — bố cục đang chạy ở Phụ lục G. Các bài học A.2 – A.6 vẫn nguyên giá trị.

Phụ lục B — vGPU và giấy phép — biên bản các sự cố đã gặp

Chương 5 và chương 14 nêu cách dùng. Phụ lục này giữ lại những lần hỏng và cách truy ra nguyên nhân — vì phần lớn thời gian vận hành vGPU là dành cho việc đó.

B.1 Nền tảng: card này đang giả trang

Sự thật	Chi tiết
Phần cứng thật	NVIDIA GeForce GTX 1660 Ti (TU116, Turing), 6 GB VRAM
Driver nhìn thấy	Quadro RTX 6000 — nhờ bản vá vgpu_unlock
Máy khách nhìn thấy	PCI\VEN_10DE&DEV_1E30&SUBSYS_132610DE — DEV_1E30 là mã của Quadro RTX 6000 giả trang, không phải 1660 Ti
Dòng card làm được	Turing (GTX 16xx, RTX 20xx). Ampere trở đi (RTX 30xx/40xx) thì KHÔNG — NVIDIA cắt ở tầng phần cứng, không vá được
Nhóm IOMMU	Nhóm 1 chỉ chứa 4 hàm của chính card (.0 VGA · .1 Audio · .2 USB · .3 UCSI) ⇒ passthrough sạch, không cần ACS override

B.2 Giấy phép là chuyện LIÊN TỤC, không phải một lần

NGUY HIỂM · ĐIỂM DỄ HIỂU SAI NHẤT CỦA TOÀN BỘ HỆ THỐNG VGPU

Driver cài một lần là xong. Nhưng driver máy khách phải xin giấy phép lại mỗi lần khởi động. Không có giấy phép hợp lệ thì máy chạy hết công suất trong 20 phút đầu rồi tụt xuống khoảng 3 khung hình/giây và tắt CUDA — hoàn toàn im lặng.

▸ Vì vậy hệ thống đã dựng sẵn một máy cấp phép tự chủ (FastAPI-DLS) tại https://172.16.10.220:20440, thay vì phụ thuộc bản dùng thử 90 ngày.

▸ Phân biệt hai trạng thái: Unlicensed (Unrestricted) = chưa tới hạn bị siết; Unlicensed (Restricted) = đã bị siết rồi.

B.3 Sự cố 1 — không xin được giấy phép, thủ phạm là ĐỒNG HỒ

Ngày 30/08/2026, máy vpn-pc không lấy được giấy phép. nvidia-smi báo Unlicensed (Restricted). Nhật ký máy cấp phép lặp mãi POST /auth/v1/origin → 200 kèm registration_pending: True, không bao giờ đi tiếp sang bước cấp thuê.

GHI CHÚ · CHUỖI NHÂN QUẢ THẬT — MỌI GIẢ THUYẾT TỰ NHIÊN ĐỀU SAI

Múi giờ của máy khách Windows để ở Pacific. Proxmox đưa đồng hồ phần cứng theo giờ địa phương của máy chủ (UTC+7); Windows diễn giải đó là PST ⇒ giờ UTC bên trong lệch 14 tiếng — trong khi giờ hiển thị trên màn hình vẫn hoàn toàn đúng. Mã thông báo ngắn hạn của máy cấp phép có exp = iat + 900 giây, rơi ngoài cửa sổ hợp lệ ⇒ máy khách vứt đi rồi quay lại bước đầu.

▸ Cách sửa (cần quyền quản trị): tzutil /s 'SE Asia Standard Time' và bật dịch vụ w32time. Giờ hiển thị không đổi, chỉ UTC nội bộ về đúng. Sau ~2 phút tự có Licensed (Expiry: +90 ngày).

▸ Cách kiểm nhanh nhất: (Get-Date).ToUniversalTime() — đừng nhìn giờ hiển thị.

▸ Cách loại trừ phía máy chủ: so với một máy khách khác đang lấy được giấy phép trên cùng máy cấp phép. Nếu máy kia chạy trọn chuỗi thì phía máy chủ vô can.

▸ Ảnh Windows LTSC mặc định để Pacific, nên mọi máy nhân bản từ bản mẫu đều dính cho tới khi sửa trong chính bản mẫu.

LƯU Ý · MỘT MANH MỐI GÂY NHIỄU ĐÃ BỊ LOẠI TRỪ

Chứng chỉ của máy cấp phép không nằm trong kho tin cậy của máy khách (curl.exe không có -k sẽ báo SEC_E_UNTRUSTED_ROOT). Điều này đúng, nhưng không phải nguyên nhân. Đây là kiểu manh mối tốn nhiều giờ nhất: nó có thật, nó nghe hợp lý, và nó vô can.

B.4 Sự cố 2 — driver GRID treo cứng máy khách

Cài driver GRID 553.74 vào Windows 10 có vGPU trên card đã vá ⇒ treo cứng máy khách. Số đo lúc treo: màn hình đen · guest agent chết · CPU đứng yên ở 4,5 % · ghi đĩa dừng · không phản hồi lệnh tắt ACPI sau 400 giây.

LƯU Ý · HAI BẪY PHỤ ĐÃ LỘ RA TRONG CÙNG VỤ NÀY

▸ Invoke-WebRequest của PowerShell không tải nổi mã thông báo giấy phép từ máy cấp phép (The underlying connection was closed), ép Tls12 cũng vô ích. Phải dùng curl.exe (có sẵn từ Windows 10 phiên bản 1803). Đã sửa trong B43.

▸ Kịch bản .ps1 đẩy vào Windows phải có dấu BOM UTF-8. PowerShell 5.1 đọc tệp không BOM bằng bảng mã ANSI ⇒ chữ tiếng Việt nát, sinh ra dấu nháy làm đứt chuỗi. Mã hoá base64 chỉ lo khâu TRUYỀN qua agent, không lo khâu ĐỌC.

B.5 Ghim phiên bản phần cứng ảo +pveN

Xem mục 7.6 cho hành vi trên giao diện. Điểm đáng nhớ ở đây là nơi lỗi xuất hiện:

NGUY HIỂM · LỖI NẰM TRONG TÁC VỤ, KHÔNG NẰM Ở LỜI GỌI API

POST .../status/start chỉ xếp hàng một tác vụ rồi trả về UPID kèm HTTP 200 ngay lập tức. Lời gọi thành công không có nghĩa là máy đã lên. Lỗi ghim rơi vào trường exitstatus của tác vụ. Muốn biết thật thì phải chờ tác vụ xong rồi mới đọc kết quả. Đây là mẫu lỗi lặp lại ở nhiều chỗ khác trong Proxmox API.

Phụ lục C — Bản mẫu Windows — những gì đã học được

Phụ lục này gom các bài học khi chuẩn hoá một máy Windows thành bản mẫu dùng chung. Chúng không thuộc về B43, nhưng ai vận hành B43 sẽ gặp.

C.1 qemu-ga tự cuộn ngược vì VSS bị tắt hẳn

Bộ cài qemu-ga MSI tự cuộn ngược sau khi cài: dịch vụ biến mất, thư mục cài không được tạo ra, mã lỗi 1603 / 0x80070422. Nguyên nhân: dịch vụ Volume Shadow Copy (VSS) bị tắt hẳn trong bản mẫu.

LƯU Ý · BẪY KÈM THEO

Bộ cài VẪN hiện hộp thoại dù được chạy với tham số /quiet — nên nếu bạn chạy nó qua guest agent và không thấy gì xảy ra, rất có thể nó đang chờ ai đó bấm nút trên một màn hình không ai nhìn thấy.

C.2 Ô Bộ nhớ đứng 100 % — thủ phạm là Sổ đếm Hiệu năng

Chẩn đoán “thiếu driver bong bóng” là quá thô. Driver có thể đã cài và chạy đủ mà vẫn không có freemem.

Bước	Lệnh / dấu hiệu	Đọc thế nào
Dấu vân tay nhận ra ngay	mem > maxmem	Đây là dấu hiệu chắc chắn nhất. Số dùng lớn hơn số cấp là điều không thể xảy ra thật.
1. Máy chủ có hỏi không?	qm config <id> \| grep balloon	Giá trị 2 nghĩa là hỏi mỗi 2 giây; Proxmox tự bật
2. Máy khách trả gì?	giá trị 18446744073709551615	Đó là 0xFFFF… — nghĩa là “không có số liệu”, không phải một con số lớn
3. last_update có nhúc nhích không?	so hai lần đọc	Đóng băng từ lúc khởi động = máy khách câm
Cách chữa	lodctr /R	Dựng lại kho Sổ đếm Hiệu năng của Windows

Lý do sâu xa: blnsvr.exe (dịch vụ bong bóng của virtio) lấy số từ kho Sổ đếm Hiệu năng. Kho đó rỗng thì dịch vụ chạy nhưng không có gì để báo về.

C.3 Card e1000 không đếm byte

Triệu chứng: Task Manager trong Windows vẽ mạng 0 Kbps trong khi máy đang tải thật 73 Mbps. netstat -e cho thấy số gói tăng đều nhưng Bytes = 0.

C.4 Chữ qua Remote Desktop bị nhoè

Nguyên nhân là đúng một bit: kịch bản tối ưu hoá của bản mẫu tắt ClearType (mặt nạ 0x90).

NGUY HIỂM · BẪY QUAN TRỌNG NHẤT: HKCU QUA GUEST AGENT LÀ HIVE CỦA SYSTEM

Guest Agent chạy dưới tài khoản SYSTEM. Mọi thao tác vào HKCU qua agent sẽ ghi vào hive của SYSTEM, không phải hive của người dùng đang đăng nhập. Sửa xong, kiểm lại thấy “đã sửa”, nhưng người dùng thật vẫn thấy chữ nhoè.

▸ Bẫy 2: schtasks /it xung khắc với /rp — không dùng chung được.

▸ Bẫy 3: hive “bẩn” (chưa được ghi xuống sạch) nuốt mất bản vá trong im lặng khi sửa nguội đĩa của bản mẫu.

C.5 Hai bẫy của cmd.exe trong tệp .bat

Bẫy	Hiện tượng	Sự thật
/? ngay sau REM	Script chết ngang, không thông báo gì	cmd.exe diễn giải /? là yêu cầu in trợ giúp, kể cả khi nó nằm trong một dòng chú thích
shift	%~dp0 trỏ nhầm thư mục	shift dịch cả %0, nên đường dẫn tới chính script bị mất

GHI CHÚ · CÁCH CHẠY THỬ MỘT TỆP .BAT THẬT — KHÔNG CÓ ĐƯỜNG TẮT

Nhân bản bản mẫu có QEMU Guest Agent, gắn ổ đĩa cài đặt trước khi bật (QEMU không cắm nóng thiết bị IDE), chờ agent lên sau ~15 giây, rồi chạy qua agent/exec. Mọi cách mô phỏng khác đều bỏ sót một khác biệt nào đó.

C.6 “Máy vẫn tên đó” không có nghĩa là “vẫn máy đó”

NGUY HIỂM · MỘT SỰ CỐ ĐÃ TỐN RẤT NHIỀU THỜI GIAN TRUY SAI HƯỚNG

Một máy tên #100 bị chẩn đoán là “agent hỏng”. Truy mãi trong hệ điều hành không ra. Sự thật: máy đã bị xoá và dựng lại từ một nguồn khác vài giờ trước đó — cùng số hiệu, cùng tên, nhưng khác ruột hoàn toàn.

▸ Trước khi chẩn đoán bên trong hệ điều hành, hãy hỏi lịch sử tác vụ của node (tasks) và sổ phả hệ lineage.json. Nếu thấy qmdestroy rồi qmclone gần đây thì mọi giả thuyết về hệ điều hành đều vô nghĩa.

▸ Đây cũng là lý do B43 xoá số liệu GPU ngay khi xoá máy: số hiệu máy ảo được cấp lại ngay, để sót thì máy mới mọc ra một quá khứ không phải của nó.

Phụ lục D — Bảng tra API

Gốc /api. Mọi phản hồi lỗi dùng dạng {"detail": "..."} của FastAPI, bằng tiếng Việt. Đếm tự động từ main.py ngày 19/09/2026: 119 endpoint trên 99 đường dẫn, cộng bốn đường của console proxy. (Bản 13/09 ghi 77 trên 62 — đã thiếu cả một số đường có từ trước ngày đó, như cấu hình node, đổi tên bản mẫu.)

Nhóm	Endpoint
Hệ thống	GET /health · GET /cache-stats · POST /cache-clear · GET /tasks/{node}/{upid} · GET /flag/{cc}.svg (ảnh cờ quốc gia tự phục vụ)
Đăng nhập	GET /auth/state · POST /login (thêm trường code khi 2FA bật) · POST /logout — cùng /health, /login.html và tiền tố /vgpu-driver/ là những đường duy nhất không cần cookie
2FA (18/09)	GET /auth/totp · POST /auth/totp/setup · POST /auth/totp/confirm · POST /auth/totp/disable
Hoạt động (18/09)	GET /nhat-ky · GET /tac-vu
Cảnh báo (18/09)	GET /canh-bao · POST /canh-bao/da-xem · POST /canh-bao/gui-thu
Console (không có tiền tố /api)	GET /console · GET /novnc/{path} · GET\|POST\|PUT\|DELETE /api2/{path} · WS /api2/json/nodes/{n}/{kind}/{id}/vncwebsocket
Node	GET\|POST /nodes · DELETE /nodes/{node} · GET\|PUT\|DELETE /nodes/{node}/config · POST /nodes/{node}/config/test · POST /nodes/{node}/wake · POST /nodes/{node}/shutdown · GET /wol-nodes · GET /nodes/{node}/metrics · GET /nodes/{node}/storages · GET /nodes/{node}/storages/{stg}/content · GET /nodes/{node}/isos · GET /nodes/{node}/templates
USB (17/09)	GET\|POST /nodes/{node}/usb
Droplet	GET\|POST /droplets · GET\|DELETE /droplets/{n}/{id} · POST /droplets/{n}/{id}/action (thêm suspend) · POST /droplets/{n}/{id}/resize · POST /droplets/clone · POST /droplets/clone-from · POST /droplets/from-image · POST /lxc
Tạm dừng (15/09)	GET\|POST /droplets/{n}/{id}/tam-dung — đọc / đặt ô tick và số đo trong máy
Xem máy	GET /droplets/{n}/{id}/network · GET .../ips · GET .../metrics · GET .../screenshot · GET .../console · PUT .../description · GET .../identity · POST .../nic-mac · GET\|POST .../o-chung · POST .../setup-disk
Snapshot	GET\|POST /droplets/{n}/{id}/snapshots · DELETE .../{snap} · POST .../{snap}/delete · POST .../{snap}/rollback
Sao lưu	GET\|DELETE /backups · POST /backups/restore · GET /backups/options · GET /backups/preview · GET /backups/running · POST /droplets/{n}/{id}/backup · GET\|PUT /backups/notes
Lịch sao lưu (18/09)	GET\|POST /backups/schedules · PUT\|DELETE /backups/schedules/{node}/{id} · POST .../{id}/enabled · POST .../{id}/run · GET .../{id}/included
vGPU	GET /nodes/{n}/vgpu · GET /nodes/{n}/vgpu-plan · GET\|POST\|DELETE /nodes/{n}/vgpu-choice · GET\|POST /nodes/{n}/vgpu-config · POST /nodes/{n}/vgpu-config/preview · GET\|POST /nodes/{n}/gpu-mode · POST /nodes/{n}/gpu-assign · DELETE /nodes/{n}/gpu-assign/{id}
Driver máy khách	GET /nodes/{n}/vgpu-driver-bundles · GET /vgpu-driver/{bundle}/{kind} · POST /droplets/{n}/{id}/install-vgpu-driver · GET .../install-vgpu-driver/status · GET .../vgpu-driver-check
Ảnh & ứng dụng	GET /images · GET /solutions · GET /nodes/{n}/appliances · POST /nodes/{n}/appliances/download · GET /nodes/{n}/images/{image_id} · POST /nodes/{n}/images/{image_id}/download · GET /dockerhub/search · GET /dockerhub/deploy-command
Dự án	GET\|POST /projects · PUT\|DELETE /projects/{name} · POST /projects/assign · GET /project-colors · PUT /projects/{name}/color
SSH	GET\|POST /sshkeys · DELETE /sshkeys/{key_id}
Ổ đĩa cài đặt	GET /nodes/{node}/setup-disk · POST /droplets/{n}/{id}/setup-disk
Phả hệ & bản mẫu	GET /templates · GET /templates/graph · POST /templates/from · PUT /templates/{n}/{id}/name · POST /templates/{n}/{id}/delete (đòi mật khẩu)

D.1 Ba hình dạng phản hồi hay bị hiểu nhầm

LƯU Ý · GET .../VGPU-DRIVER-CHECK — GÓC KHUẤT NGUY HIỂM NHẤT CỦA API

Phản hồi có cả config.driver lẫn state, và chúng có thể nói ngược nhau. config.driver là ảnh chụp từ file cấu hình lúc chưa hỏi máy khách; nó có thể là unknown trong khi state là ok. Luôn đọc state ở cấp ngoài cùng.

▸ Giá trị state: ok · missing · na · unknown.

▸ Trả 409 cho LXC và cho máy không gắn card.

▸ Máy đang tắt ⇒ state: unknown + running: false + lý do — không phải lỗi.

▸ Khoá mismatch xuất hiện khi VRAM cấu hình lệch VRAM máy khách báo về quá 64 MiB ⇒ máy vẫn chạy driver của lần gắn card trước, chưa tắt bật lại. Rất dễ bỏ qua vì chip vẫn xanh.

Phụ lục E — Thuật ngữ

Thuật ngữ	Định nghĩa	Trong hệ thống này
Hypervisor loại 1	Lớp ảo hoá chạy trực tiếp trên phần cứng	Proxmox VE = Debian + KVM trong nhân Linux
KVM / QEMU	Mô-đun ảo hoá của nhân Linux + trình giả lập phần cứng	Công nghệ tạo ra các Droplet có phần cứng ảo độc lập
LXC	Ảo hoá cấp hệ điều hành — container dùng chung nhân với máy chủ	Tab Ứng dụng TurnKey; nhánh API /lxc khác hẳn /qemu
Droplet	Cách B43 gọi một máy ảo hoặc container	Phân biệt bằng trường kind
Node	Một máy chủ vật lý chạy Proxmox	pve-wp2-01, pve-wp2-02 — độc lập
Pool	Nhóm tài nguyên của Proxmox	Nền phía dưới của khái niệm Dự án
LVM-thin	Cấp phát mỏng trên LVM — chỉ chiếm chỗ khi thật sự ghi	local-lvm và vmstore
Thin pool metadata	Vùng riêng ghi bản đồ khối của thin pool	Đầy vùng này thì pool thành chỉ đọc; snapshot ăn nhanh nhất
Snapshot	Điểm phục hồi vi sai, nằm cùng ổ với máy	Tab Snapshot. Không thay được sao lưu
VZDump	Định dạng sao lưu nguyên khối của Proxmox	Tệp .vma.zst, nén zstd. Không chứa snapshot
Nhân bản liên kết	Máy con dùng chung đĩa gốc, chỉ ghi phần khác biệt	Mặc định khi tạo từ bản mẫu. Tốn 0 GB lúc đầu
Cloud-init	Chuẩn tự cấu hình lúc khởi động lần đầu	Nhúng khoá SSH, nới đĩa, cài qemu-guest-agent. LXC không có
QEMU Guest Agent	Dịch vụ trong máy khách, nói chuyện với máy chủ qua virtio	Nguồn của IP, dung lượng đĩa, trạng thái driver, và kênh cài driver
mdev	Thiết bị trung gian (mediated device) của nhân Linux	Cơ chế cắt lát card đồ hoạ. Chuỗi hostpci0 phải là <pci>,mdev=<type>
vgpu_unlock	Bản vá cho driver nhìn card chơi game như card chuyên nghiệp	GTX 1660 Ti → Quadro RTX 6000. Turing được, Ampere trở đi thì không
Homogeneous vGPU	Ràng buộc: mọi lát trên một card phải cùng cỡ khung đệm	Khoá theo cỡ, không theo mã hồ sơ — 1A/1B/1Q dùng lẫn được
RRD	Cơ sở dữ liệu vòng, kích thước cố định	Nguồn của đồ thị 24 giờ: 1440 điểm, bước 60 giây
Bộ ngắt mạch	Cơ chế hỏng-nhanh khi một phụ thuộc đã chết	Node offline ⇒ mọi lời gọi hỏng trong 0,0000 giây
Stale-while-revalidate	Trả bản cũ ngay, làm mới ngầm ở nền	Cách cache.py hoạt động
Magic Packet	Khung lớp 2 dùng để đánh thức máy qua mạng	Không đi qua bộ định tuyến ⇒ phải nhờ node còn sống chuyển tiếp
PBS	Proxmox Backup Server — máy chủ sao lưu lưu theo khối	CT 201, kho pbs (từ 11/09/2026) — Phụ lục G
Chống trùng lặp	Khối giống nhau giữa các bản sao lưu chỉ lưu một lần	64,8 GiB đĩa ảo → 21 GB trong PBS
Thu gom rác (GC)	Xoá khối không còn bản sao lưu nào tham chiếu tới	Thứ Bảy 02:00. Chỉ xoá khối đã quá ~24 giờ
SMR	Ghi chồng mái ngói — ghi tuần tự ổn, ghi đè ngẫu nhiên rất chậm	Ổ 4 TB sdc: kho sao lưu + ổ chung. Không chống phân mảnh
CMR	Ghi rãnh thường	Ổ 500 GB sdd: ổ nhanh, profile Chrome
LVM (VG / LV)	Nhóm ổ luận lý và các khối cắt ra từ nhóm đó	hdd4t (pbs, share), hdd500 (fast); nới khối không phải dời dữ liệu
Bind mount	Gắn thẳng một thư mục của máy chủ vào container	Ổ chung vào CT 200 — không phải kho Proxmox nên không hiện trong bảng kho
Container unprivileged	Container dịch mã người dùng thêm 100000 so với máy chủ	lotus uid 1000 trong CT = 101000 trên node
SMB / Samba	Giao thức chia sẻ file của Windows / phần mềm phục vụ trên Linux	\\10.77.0.10\share và \\10.77.0.10\fast
Previous Versions	Tab trong Windows để mở lại bản cũ của file	Đọc cây ảnh chụp hardlink qua vfs_shadow_copy2
Cầu nội bộ vmbr1	Cầu mạng ảo không cắm cổng vật lý nào	10.77.0.0/24; địa chỉ không đổi khi node dời site
TOTP / 2FA	Mã 6 số đổi mỗi 30 giây, tính từ một khoá chung giữa máy chủ và điện thoại (RFC 6238)	Lớp đăng nhập thứ hai, trang Bảo mật — mục 15.3
Chống phát lại	Không nhận lại một mã đã dùng	B43 nhớ bước thời gian của mã vừa nhận
Nhịp chung	Một luồng lấy mẫu duy nhất, một mốc thời gian cho mọi nguồn	b43-nhip-chung, 10 giây / 60 giây — mục 2.6
Trễ trở lại (hysteresis)	Báo ở một mức, chỉ coi là hết ở mức thấp hơn	Nhiệt báo 80, hết dưới 75; kho báo 80, hết dưới 77
Tạm dừng (suspend to disk)	Ghi toàn bộ RAM ra đĩa rồi tắt; bật lại là về đúng phiên cũ	Hai đường: todisk của Proxmox, hoặc ngủ đông trong Windows với máy có card
Ngủ đông (hibernate)	Như trên nhưng do chính hệ điều hành khách làm	Tệp hiberfil.sys trên ổ C: của máy — chiếm chỗ vĩnh viễn
TCC / THERMTRIP	CPU tự hạ xung khi quá nóng / phần cứng cắt điện khi nóng hơn nữa	pve-001: 83 °C và 85 °C
PECI	Đường bo mạch đọc nhiệt của CPU	Số nct6779 · PECI Agent — cao hơn số Package 5–6 °C
Job vzdump	Lịch sao lưu của Proxmox (/cluster/backup)	Thẻ Lịch sao lưu tự động — mục 12.1
Prune / keep-daily…	Luật cắt tỉa: giữ bao nhiêu bản mỗi ngày, tuần, tháng	PBS: 7 ngày · 4 tuần · 6 tháng — sinh ra ba nhóm lưu trữ
Incoming Webhook (Slack)	URL nhận một gói JSON rồi đăng thành tin nhắn vào một kênh	B43_SLACK_WEBHOOK
Gzip	Nén nội dung trên đường truyền	app.js 491,6 → 147,8 KB

Phụ lục F — Nguồn dữ liệu và cách tài liệu này được dựng

Phần này để người đọc sau có thể kiểm chứng lại mọi con số, hoặc dựng lại tài liệu khi hệ thống thay đổi.

Loại nội dung	Nguồn	Cách kiểm lại
Ảnh chụp giao diện	Chụp trực tiếp qua trình duyệt điều khiển B35, ngày 07/09/2026	Chạy lại bộ kịch bản chụp trong tmp/b43_hb2/
Toạ độ đánh số trên ảnh	getBoundingClientRect() của chính phần tử, lưu kèm mỗi ảnh dưới dạng .json	Số luôn rơi đúng chỗ dù giao diện đổi kích thước; chạy lại annotate.py
Sơ đồ	Vẽ bằng chương trình từ số liệu thật (diagrams.py)	Sửa số trong tệp rồi chạy lại
Ảnh minh hoạ khái niệm	Sinh bằng mô hình ảnh của Gemini theo đặc tả tmp/00_IMAGE_REQUEST_B43_HANDBOOK.md	Đặc tả ghi rõ phong cách, bảng màu, ràng buộc chữ
Thông số phần cứng	GET /api/nodes trên hệ thống thật	curl -b cookie.txt http://127.0.0.1:20430/api/nodes
Danh sách máy ảo, dự án	GET /api/droplets, GET /api/projects	Tương tự
Mã phần tử HTML	Đọc trực tiếp DOM của trang đang chạy	Bộ kịch bản discover.py
Hành vi và bẫy kỹ thuật	B43_Lotus_Cloud/README.md và docs/huong-dan-su-dung-va-kiem-thu.md	Hai tệp này là nguồn sự thật của đội phát triển
Biên bản sự cố ở phụ lục A–C	Nhật ký khảo sát trên hệ thống thật, kèm số đo	Ngày tháng được ghi trong từng mục
Phụ lục G (11/09/2026)	SSH trực tiếp vào pve-001, API của PBS, ảnh chụp B35 cùng ngày, docs/o-chung-sharestore-ke-hoach.md	Kịch bản cap_g.py, diagrams_g.py, c12_appendix_g.py trong tmp/b43_hb2/
Bản cập nhật 19/09/2026	git log 13/09 → 18/09 của B43_Lotus_Cloud (28 commit); §16.24 – 16.34 của tài liệu kỹ thuật; ảnh chụp B35 ngày 19/09; lscpu/free trên pve-001; GET /api/canh-bao (lịch sử thật); đếm route tự động từ main.py	cap19.py, run_annotate19.py, diagrams19.py, c13_appendix_hi.py trong tmp/b43_hb2/. Chụp lại phải qua 2FA: cap_lib.ma_2fa()

LƯU Ý · TÀI LIỆU NÀY MÔ TẢ MỘT HỆ THỐNG ĐANG THAY ĐỔI

B43 vẫn đang được phát triển. Khi màn hình thật khác với ảnh trong sách, màn hình thật đúng. Cách kiểm nhanh nhất một mô tả còn đúng hay không: mở đúng trang đó, bấm ? Hướng dẫn — hướng dẫn tại chỗ nằm trong mã nguồn nên nó luôn đi cùng phiên bản đang chạy.

▸ Trạng thái hệ thống lúc biên soạn được ghi đầy đủ ở phần Lời nói đầu.

▸ Riêng lúc chụp ảnh, pve-wp2-01 đang tắt — nên nhiều hình cho thấy trạng thái offline của node đó. Đó là ảnh thật, không phải dựng lại.

Phụ lục G — Ổ đĩa, kho sao lưu và ổ chung trên pve-001 — cập nhật 11/09/2026

GHI CHÚ · PHỤ LỤC NÀY NÓI VỀ THỜI ĐIỂM NÀO, VÀ LẤY SỐ TỪ ĐÂU

Mọi con số dưới đây đo trực tiếp trên máy ngày 11/09/2026 — qua SSH vào node, qua API của Proxmox Backup Server, và qua ảnh chụp giao diện B43 cùng ngày. Tài liệu kỹ thuật gốc của phần này là docs/o-chung-sharestore-ke-hoach.md. Phụ lục A là biên bản của bố cục cũ (29/08/2026) và được giữ nguyên; phụ lục này mô tả bố cục đang chạy.

▸ pve-wp2-02 trong các chương trước chính là pve-001 hôm nay — cùng một máy, đã đổi tên, chuyển sang nhận địa chỉ DHCP và có thể dời giữa ba site. Lúc biên soạn phụ lục này máy nằm ở WP3, địa chỉ 172.16.30.102.

▸ Ảnh chụp ở các chương trước vẫn là ảnh ngày 07/09/2026 và vẫn ghi tên cũ.

▸ Phụ lục được cập nhật lần hai vào trưa 11/09/2026: B43 đã sửa trang Hạ tầng và trang Sao lưu (G.3, G.6), ổ chung nới lên 3,0 TB và kho PBS lên 635 GB (G.7). Nguồn: o-chung-sharestore-ke-hoach.md §13.4–13.6 và B43_Lotus_Cloud/docs/huong-dan-su-dung-va-kiem-thu.md §16.26.

G.1 Năm ổ vật lý và vai trò của từng ổ

Máy có ba ổ thể rắn (một NVMe, hai SATA) và, từ ngày 11/09/2026, hai ổ cơ. Sơ đồ dưới đi từ ổ vật lý, qua nhóm ổ luận lý (LVM), tới khối và người dùng cuối cùng.

Hình G.1. Bố cục lưu trữ của pve-001 ngày 11/09/2026: năm ổ vật lý, bốn nhóm LVM, và ai dùng khối nào.

Ổ	Model · công nghệ	Cỡ	Sức khoẻ lúc đo	Vai trò
nvme0n1	Samsung 970 EVO Plus · SSD NVMe	250 GB	94 % — ổ tự khai hạn ghi còn lại	Hệ điều hành Proxmox; kho local và local-lvm
sda	Samsung 850 EVO · SSD SATA	250 GB	92 % — ổ tự khai	Nửa thứ nhất của vmstore
sdb	Micron 1100 · SSD SATA	256 GB	Kéo điểm vmstore xuống 78 % (kho lấy ổ yếu nhất)	Nửa thứ hai của vmstore
sdc	Seagate ST4000DM004 · HDD 3,5 inch · SMR · 5400 vòng/phút	4 TB	0 sector hỏng · 0 sector chờ · 25.088 giờ chạy	Kho PBS 646 GiB + ổ chung 3080 GiB
sdd	WD Black WD5000LPLX · HDD 2,5 inch · CMR · 7200 vòng/phút	500 GB	0 sector hỏng · 0 sector chờ · 11.622 giờ chạy	Ổ nhanh 466 GiB

NGUY HIỂM · VMSTORE VẪN KHÔNG CÓ DƯ THỪA

Hai ổ sda + sdb vẫn ghép nối tiếp như Phụ lục A.3 đã ghi. Hỏng một ổ là mất cả vmstore. Điểm khác từ 11/09/2026: đĩa máy ảo trên đó giờ có bản sao lưu tự động nằm trên một ổ khác (sdc) — xem G.5.

SMR và CMR — vì sao hai ổ cơ được giao hai việc khác nhau

Hai ổ cơ nhìn giống nhau trong lsblk (ROTA = 1), nhưng cách ghi dữ liệu lên mặt đĩa khác hẳn nhau, và đó là thứ quyết định ổ nào làm việc gì.

	SMR — ổ sdc 4 TB	CMR — ổ sdd 500 GB
Cách ghi	Rãnh ghi chồng lên nhau như mái ngói	Rãnh ghi tách rời
Ghi tuần tự khối lớn	Ổn	Ổn
Ghi đè ngẫu nhiên, nhiều file nhỏ	Chậm hơn nhiều lần — phải ghi lại cả dải	Bình thường
Hợp với	Kho sao lưu, kho lưu trữ, file lớn	Profile Chrome, file nhỏ, truy cập ngẫu nhiên
Căn cứ lúc đo	smartctl tự khai: Seagate BarraCuda 3.5 (SMR)	smartctl: Western Digital Black Mobile · zoned = none

G.2 Chức năng từng nơi lưu — dùng cho việc gì, KHÔNG dùng cho việc gì

Nơi	Loại	Nằm trên · đã dùng	Dùng cho	KHÔNG dùng cho
local	Kho dir của Proxmox	NVMe, chung phân vùng hệ điều hành · 23/66 GB	ISO, mẫu container, snippets; bản vzdump cũ của VM 102	Bản sao lưu mới — đầy phân vùng này là Proxmox ngừng ghi log và cấu hình
local-lvm	lvmthin	NVMe · 2,4/137 GB	Rootfs của CT 200 và CT 201; đĩa máy cần I/O cao	—
vmstore	lvmthin	SSD sda + sdb · 79/466 GB	Đĩa máy ảo 100, 102 (bản mẫu), 103	Nơi giữ bản sao lưu duy nhất của bất cứ thứ gì
pbs	Kho pbs — nói chuyện qua mạng với CT 201	HDD sdc, khối hdd4t/pbs · 21/635 GB	Bản sao lưu máy ảo và container	Đĩa máy ảo; file dùng chung
\\10.77.0.10\share	Ổ mạng SMB — không phải kho Proxmox	HDD sdc, khối hdd4t/share · 3,0 TB	File lớn trao đổi giữa các máy ảo; kho lưu trữ	Thư mục bung sẵn hàng nghìn file nhỏ; đĩa máy ảo
\\10.77.0.10\fast	Ổ mạng SMB — không phải kho Proxmox	HDD sdd, khối hdd500/fast · 458 GB	Profile Chrome đóng gói tar trong profiles\; file nhỏ cần nhanh	Thứ cần chống chết ổ — ảnh chụp của nó nằm cùng ổ

G.3 Trang Hạ tầng: bảng Kho lưu trữ, mục Ổ chung và vạch đỏ 80%

Bản sáng 11/09/2026 của phụ lục này ghi hai chỗ thiếu trên trang Hạ tầng: bảng Kho lưu trữ không thấy 3,4 TB ổ cơ mới, và dòng pbs trống đúng hai cột Loại ổ, Health. Trưa cùng ngày B43 đã được sửa. Mọi ảnh trong mục này chụp sau khi sửa.

Hình G.2. Bảng Kho lưu trữ sau khi sửa: dòng pbs có Loại ổ và Health, mỗi thanh Mức dùng có vạch đỏ 80%.

Số	Thành phần	Giải thích
①	Tiêu đề Kho lưu trữ	Bảng liệt kê đúng các mục trong /etc/pve/storage.cfg của node — không hơn, không kém. Ổ chung và ổ nhanh không khai ở đó nên không có ở đây; chúng nằm ở mục Ổ chung bên dưới.
②	Loại ổ NVMe của local	Truy ngược được: kho kiểu dir → điểm gắn → thiết bị nvme0n1. Tên bắt đầu bằng nvme nên là NVMe, không phải SSD SATA.
③	Loại pbs	Kiểu kho pbs: Proxmox nói chuyện với một máy chủ qua mạng (10.77.0.20:8007) — không phải một thư mục, cũng không phải một nhóm ổ.
④	Loại ổ HDD của pbs	B43 lần theo địa chỉ server của kho tới container đang giữ địa chỉ đó (CT 201), đọc thư mục datastore trong /etc/proxmox-backup/datastore.cfg, rồi theo mountpoint /mnt/datastore ← /mnt/pbs ra khối hdd4t/pbs và ổ sdc. Rê chuột lên huy hiệu thấy ổ: sdc · qua CT 201 · /mnt/pbs. PBS đặt ở máy khác thì vẫn để trống như NFS, CIFS — đoán là nói dối.
⑤	Health 95%* của pbs	Điểm của ổ sdc — cùng số với hàng share ở mục Ổ chung vì hai thứ nằm trên cùng một ổ. Dấu *: điểm B43 chấm cho ổ cơ, vì SMART không có phần trăm sức khoẻ cho ổ cơ.
⑥	Đã dùng / Tổng 21/635 GB	Dung lượng kho PBS sau khi nhập nốt phần chưa cấp của nhóm hdd4t (G.7). Bản sáng ghi 21/491 GB.
⑦	Vạch đỏ ở mốc 80 %	Có ở mọi thanh Mức dùng: bảng Kho, mục Ổ chung, và bảng bóc tách khi bấm một dòng kho. Thanh vượt vạch chuyển đỏ. Rê chuột lên thanh hiện lời nhắc chừa khoảng 20 % trống.
⑧	Health 78% của vmstore	Để đối chiếu: kho nằm trên nhiều ổ thì lấy điểm của ổ yếu nhất, không lấy trung bình.

LƯU Ý · LỖI LỘ RA LÚC SỬA: MỌI Ổ CƠ BỊ GỌI LÀ SSD

Khi dòng pbs vừa có số, nó ghi ổ SMR 4 TB là SSD. Nguyên nhân: lsblk -r in hai dấu cách liền nhau khi cột ổ cha của một ổ gốc bỏ trống, còn mã tách chữ gộp hai dấu cách làm một — dòng của ổ gốc bị bỏ qua, mất luôn cờ ổ quay. Đã sửa cùng lúc.

▸ Lỗi nằm im từ trước vì .env khai tay loại ổ cho các kho cũ; chỉ lộ ra khi có kho không nằm trong bản khai tay đó.

▸ Vì sao nên biết: một bản khai tay đứng trên kết quả dò sẽ che lỗi của bộ dò.

Hình G.3. Thẻ chi tiết Health của dòng pbs — ổ sdc nằm dưới kho. Nền trang được ẩn đi cho dễ đọc.

Số	Thành phần	Giải thích
①	Thẻ chi tiết	Mở khi rê chuột hoặc chuyển tiêu điểm bàn phím vào huy hiệu Health (hình trước, số ⑤). Liệt kê từng ổ nằm dưới kho — với pbs là một ổ sdc, điểm 95%*.
②	Dòng model	ST4000DM004-2U9104 · số sê-ri · 5400 vòng/phút.
③	Chip SMR	Công nghệ ghi của ổ cơ. Hợp làm đích sao lưu; đừng đưa vào mảng RAID. Rê chuột lên chip để xem căn cứ.
④	Bảng chỉ số	Tuổi và môi trường · Hao mòn · Năm thuộc tính dự báo hỏng · Đường truyền — luôn hiện cả chỉ số bằng 0. Lúc chụp: 25.089 giờ chạy, 0 sector hỏng, 0 sector chờ; 188 Command Timeout khác 0 — đó là thứ trừ 5 điểm, còn 95. 199 UDMA CRC Error = 3 là lỗi cáp, không trừ điểm ổ.
⑤	Chú thích dấu *	Giải thích cách B43 chấm điểm ổ cơ: bắt đầu từ 100, trừ theo các chỉ số sự cố.

Mục Ổ chung — hệ tệp không phải kho Proxmox

/mnt/share/data và /mnt/fast/data được gắn thẳng vào CT 200 bằng bind mount (các dòng mp0 … mp3 trong cấu hình container), không đi qua storage.cfg. Đó là cố ý: khai chúng thành kho Proxmox kiểu dir là mở ra lựa chọn đặt đĩa máy ảo lên đây trong mọi ô chọn kho — tức là mời người sau đặt đĩa hệ điều hành lên một ổ SMR. Vì thế B43 có một mục riêng ngay dưới bảng Kho, đọc thẳng hệ tệp đang gắn trên máy chủ.

Hình G.4. Mục Ổ chung trên thẻ máy chủ pve-001: hai ổ mạng SMB mà bảng Kho lưu trữ không thấy.

Số	Thành phần	Giải thích
①	Tiêu đề Ổ chung	Chỉ hiện trên máy chủ có hệ tệp như vậy. Nếu lần đo gần nhất hỏng hoặc số đã cũ hơn 10 phút, cạnh tiêu đề có chữ đỏ số đo lúc ….
②	Dòng dẫn	Nhắc vì sao bảng Kho ở trên không thấy những ổ này.
③	Tên share	Tên share Samba — cũng là chữ cuối của địa chỉ SMB.
④	Nhãn vai trò	chia sẻ SMB (container Samba đang phục vụ) · gắn vào container (có container gắn nhưng không thấy share) · chưa ai dùng (đã gắn trên máy chủ, không container nào dùng).
⑤	Điểm gắn · nhóm ổ	/mnt/share · VG hdd4t — nơi hệ tệp nằm trên máy chủ và nhóm LVM chứa nó.
⑥	Địa chỉ	\\10.77.0.10\share — gõ vào File Explorer trên máy ảo. Máy ảo phải có card mạng vào cầu vmbr1 (G.4).
⑦	Container phục vụ	CT 200 sharestore-smb.
⑧	Loại ổ	Cùng cách truy như bảng Kho: điểm gắn → khối LVM → ổ vật lý sdc.
⑨	Health	Cùng số với bảng Kho khi cùng ổ — pbs và share đều 95%*.
⑩	Ảnh chụp	Số bản chụp chỉ-đọc và giờ chụp gần nhất. Lấy lại tệp cũ qua Previous Versions (G.4). Tên thư mục @GMT-… trên đĩa là giờ UTC; B43 đổi sang giờ máy khi hiển thị.
⑪	Đã dùng / Tổng	0,0/3,0 TB — cỡ sau khi nới share (G.7).
⑫	Mức dùng	Thanh có vạch đỏ 80 %. Với share, mốc đó là khoảng 2,4 TB.

Dưới bảng có thêm dòng Nhóm ổ … còn … chưa cấp phát khi nhóm LVM còn từ 1 GiB trống trở lên. Từ trưa 11/09/2026 nhóm hdd4t đã cấp hết (G.7), nên dòng này không còn hiện.

GHI CHÚ · MỤC NÀY ĐO BẰNG GÌ — VÀ CỐ Ý KHÔNG LÀM GÌ

Một lượt SSH mỗi 2 phút: findmnt lấy dung lượng hệ tệp, đọc cấu hình container, chạy testparm trong container Samba để biết tên share, liệt kê thư mục ảnh chụp, và vgs / lvs.

▸ Không chạy du: quét cả ổ SMR hàng triệu tệp là vài phút cày đầu từ.

▸ Không hiện lại /mnt/pbs hay thư mục của kho dir: bảng Kho đã có hàng cho chúng — hiện hai lần là mời người đọc cộng hai lần.

▸ Kết quả ghi xuống /data/hw_cache.json, nên mở trang ngay sau khi B43 khởi động lại vẫn có số.

Hình G.5. Hai đường đo trên trang Hạ tầng: bảng Kho lưu trữ đọc storage.cfg, mục Ổ chung đọc hệ tệp đang gắn.

root@pve-001:~# df -h /mnt/pbs /mnt/share /mnt/fast

Filesystem Size Used Avail Use% Mounted on

/dev/mapper/hdd4t-pbs 635G 21G 610G 4% /mnt/pbs

/dev/mapper/hdd4t-share 3.1T 2.1M 3.1T 1% /mnt/share

/dev/mapper/hdd500-fast 458G 2.2M 458G 1% /mnt/fast

root@pve-001:~# vgs

VG #PV #LV #SN Attr VSize VFree

hdd4t 1 2 0 wz--n- <3.64t 0

hdd500 1 1 0 wz--n- <465.76g 0

df -h ghi 3.1T cho share vì nó làm tròn lên; B43 và Windows ghi 3,0 TB — cùng một cỡ, xem G.7.

G.4 Hướng dẫn dùng ổ chung và ổ nhanh

Mục	Giá trị
Ổ chung	\\10.77.0.10\share — B43 gắn thành ổ S: trên Windows, /mnt/o_chung trên Linux
Ổ nhanh	\\10.77.0.10\fast — B43 gắn thành ổ F: trên Windows, /mnt/o_nhanh trên Linux
Thư mục profile Chrome	\\10.77.0.10\fast\profiles
Tài khoản	lotus — một tài khoản dùng chung; mật khẩu là mật khẩu chung của nhà, không ghi trong tài liệu nào
Máy phục vụ	CT 200 sharestore-smb · Samba 4.22 · chỉ nhận SMB3 trở lên
Mạng	Cầu nội bộ vmbr1 10.77.0.0/24 — không có cổng vật lý, không lộ ra LAN của site

GHI CHÚ · VÌ SAO ĐỊA CHỈ LÀ 10.77.0.10 CHỨ KHÔNG PHẢI MỘT ĐỊA CHỈ LAN

Node nhận địa chỉ DHCP và có thể dời giữa WP1, WP2, WP3. Nếu ổ chung nằm trên LAN, mỗi lần dời site là mọi máy ảo mất ổ S:. Cầu vmbr1 nằm trong máy, nên 10.77.0.10 giống hệt ở mọi site — kể cả khi rút hẳn dây mạng.

▸ Kiểm chứng thật: ngày 11/09/2026 node được dời từ WP1 (172.16.10.66) sang WP3 (172.16.30.102); sau khi khởi động lại, 10.77.0.10:445 vẫn mở — xem G.9.

MẸO · CÁCH THƯỜNG DÙNG: MỘT Ô TÍCH TRONG B43

Từ 12/09/2026 không phải làm gì bằng tay nữa. Mở máy ảo → tab Cài đặt → thẻ Ổ chung (mạng), tick ô là B43 tự cắm card, tạo tài khoản Samba riêng cho máy, rồi gắn ổ F: và S: cho mọi phiên đăng nhập trong máy. Xem mục 10.3, Khối 5.

▸ Phần còn lại của mục này là đường làm tay dự phòng — khi B43 không chạy được, hoặc với máy không do B43 quản lý.

Làm tay (dự phòng) — điều kiện để một máy ảo thấy được ổ chung

Máy ảo phải có card mạng thứ hai cắm vào vmbr1. Từ tối 11/09/2026 cầu này đã có DHCP riêng (lotus-dhcp-vmbr1, dải 10.77.0.100–199, không phát gateway và DNS), nên card thứ hai tự nhận địa chỉ — không phải đặt tay như bản trước của phụ lục này ghi. Các địa chỉ cố định đã dùng: .10 Samba · .20 PBS · .254 chính node.

1. Trên node, thêm card cùng kiểu với net0: qm set <vmid> --net1 virtio,bridge=vmbr1 (máy nào còn e1000 thì thêm e1000, kẻo Windows không có driver). Không thêm firewall=1. Windows chưa thấy card mới thì tắt hẳn máy rồi bật lại.

2. Để card tự xin DHCP; đừng đặt gateway hay DNS cho nó — Internet vẫn đi đường card cũ.

3. Đăng nhập RDP bằng chính tài khoản sẽ dùng ổ, mở Command Prompt, lưu mật khẩu: cmdkey /add:10.77.0.10 /user:lotus /pass (lệnh sẽ hỏi mật khẩu).

4. Gắn ổ: net use S: \\10.77.0.10\share /persistent:yes và net use F: \\10.77.0.10\fast /persistent:yes.

NGUY HIỂM · ĐỪNG LÀM BƯỚC 3 VÀ 4 QUA GUEST AGENT

Ổ mạng trong Windows thuộc về từng phiên đăng nhập. Guest agent chạy dưới quyền SYSTEM — gọi net use qua nó tạo ổ S: trong phiên của SYSTEM: lệnh báo thành công, ổ có thật, và người dùng RDP vào không thấy gì. Cùng họ với bẫy đọc HKCU qua guest agent ra nhầm hive của SYSTEM.

GHI CHÚ · ĐÃ CHẠY THỬ THẬT — BẰNG Ô TÍCH, KHÔNG PHẢI BỐN BƯỚC TRÊN

Ngày 11–12/09/2026 đường này đã được kiểm trọn vòng trên máy thật, qua thẻ Ổ chung (mạng) của B43: máy 103 Windows thấy cả F: lẫn S: ngay trong phiên RDP và ghi được file; một máy Debian 13 mount được cả hai; hai máy đọc/ghi chéo, file trên máy chủ thuộc 101000 (lotus). Bỏ tick gỡ sạch trong khoảng 4 giây.

▸ Bốn bước làm tay ở trên chưa chạy thử trên máy ảo nào — chúng chỉ là đường dự phòng.

▸ Đường SMB còn được kiểm riêng bằng smbclient ngay trên node: liệt kê hai share, ghi file vào cả hai, đọc lại, và lấy lại nội dung cũ từ ảnh chụp.

▸ Chi tiết và các bẫy đã vấp: B43_Lotus_Cloud/docs/huong-dan-su-dung-va-kiem-thu.md §16.27.

Lấy lại file bị ghi đè hoặc xoá nhầm — Previous Versions

1. Trong Windows, chuột phải vào file hoặc thư mục chứa nó trên ổ S: / F: → Properties.

2. Mở tab Previous Versions. Mỗi dòng là một mốc chụp, giờ hiển thị theo giờ máy.

3. Chọn mốc trước lúc sự cố → Open để xem, Copy để chép ra chỗ khác, Restore để ghi đè lại bản đang có.

Ổ	Chụp khi nào	Giữ lại những bản nào	Bản chụp nằm ở
fast	Mỗi giờ, phút 00	Mọi bản trong 24 giờ qua, và bản đầu tiên của mỗi ngày trong 14 ngày	/mnt/fast/snap — cùng ổ sdd
share	00:10 · 06:10 · 12:10 · 18:10	Như trên	/mnt/share/snap — cùng ổ sdc

ĐÚNG THIẾT KẾ · BẢN CHỤP NẰM NGOÀI TẦM VỚI CỦA MÁY ẢO — ĐÚNG THIẾT KẾ

Thư mục snap không nằm trong cây share, và được gắn vào CT 200 ở chế độ chỉ đọc (ro=1). Một máy ảo dính mã độc có ổ S: toàn quyền vẫn không xoá được lịch sử, kể cả khi chiếm được cả tiến trình Samba.

LƯU Ý · ẢNH CHỤP HARDLINK KHÔNG PHẢI ẢNH CHỤP ZFS — CHI PHÍ ĐĨA KHÁC HẲN

Hệ tệp là ext4, không có chức năng chụp nhanh, nên bộ chụp lotus-snap dựng một cây hardlink bằng rsync --link-dest. File không đổi dùng chung chỗ với bản chụp trước. Nhưng bản chụp không bao giờ dùng chung chỗ với file đang sống — nếu dùng chung, lần ghi đè tại chỗ tiếp theo sẽ sửa luôn cả bản chụp.

▸ ⇒ Cây ảnh chụp tốn thêm khoảng bằng dung lượng dữ liệu đang có. Ổ chung chứa 1 TB thì ảnh chụp chiếm thêm khoảng 1 TB.

▸ File đã sửa thì tốn nguyên cả file, không chỉ phần đã đổi.

▸ Đo trên máy: cp --reflink=always trên ext4 báo Operation not supported. Hướng rẻ hơn là đổi share sang XFS (có reflink) — chưa quyết, vì XFS không co lại được.

Hai máy ghi cùng một file thì sao

Kiểu ghi	Chuyện gì xảy ra
Word, Excel, phần mềm khai báo khoá khi mở file	Máy thứ hai bị chặn, chỉ mở được ở chế độ đọc
Chương trình khai khoá theo vùng byte	Samba cưỡng chế khoá giữa các máy
Script tự viết, copy, robocopy	Không khai khoá gì ⇒ máy ghi sau thắng, lặng lẽ. Đường lùi duy nhất là Previous Versions

Quy tắc giữ hai ổ cơ khoẻ

G.5 Sao lưu — cái gì, khi nào, nằm ở đâu, giữ bao lâu

Hình G.6. Từng loại dữ liệu, cơ chế bảo vệ, và nơi đặt bản sao. Xanh: khác ổ. Cam: cùng ổ.

Dữ liệu	Máy / đường dẫn	Cơ chế	Khi nào	Bản sao nằm ở	Giữ
Đĩa máy ảo	VM 100 may-goc-gpu-gpm · VM 102 template01-win10-gpu · VM 103 vpn-pc-01	vzdump → PBS, chế độ snapshot	23:30 mỗi đêm	Kho PBS local · /mnt/pbs · ổ sdc	7 ngày · 4 tuần · 6 tháng
Rootfs container	CT 200 sharestore-smb · CT 201 pbs	Như trên	23:30 mỗi đêm	Như trên	Như trên
Ổ chung	/mnt/share/data	lotus-snap, cây hardlink	00:10 · 06:10 · 12:10 · 18:10	/mnt/share/snap · cùng ổ sdc	24 giờ + 14 ngày
Ổ nhanh	/mnt/fast/data	lotus-snap, cây hardlink	Mỗi giờ, phút 00	/mnt/fast/snap · cùng ổ sdd	24 giờ + 14 ngày
Bản vzdump cũ	VM 102, ngày 02/09/2026, 13 GB	—	—	Kho local · NVMe	Tới khi xoá tay
Dữ liệu riêng của B43, .env, mã nguồn	HP1	Xem mục 16.2	—	—	—

Job 23:30 được tạo lúc 02:35 ngày 11/09/2026 nên lần chạy tự động đầu tiên là 23:30 cùng ngày. Lúc biên soạn, kho PBS có ba bản chạy tay để kiểm chứng: CT 200, VM 100, VM 102.

NGUY HIỂM · NHỮNG THỨ KHÔNG ĐƯỢC BẢO VỆ

▸ Ổ chung và ổ nhanh không vào PBS. vzdump bỏ qua bind mount — đã kiểm: bản sao lưu CT 200 chỉ gồm root.pxar, không có dữ liệu share. Đường lùi của hai ổ này chỉ là ảnh chụp nằm cùng ổ.

▸ Chết ổ sdc là mất cùng lúc: toàn bộ bản sao lưu PBS, ổ chung, và ảnh chụp của ổ chung.

▸ Chết node là mất tất cả. Kho pbs nằm trên chính pve-001 — nó không thay được điều kiện của kịch bản 17.3.

▸ Tầng 2 — đẩy bản sao ra ngoài máy — chưa có. NAS1 172.16.10.201 và NAS2 172.16.20.201 đều ping được từ node, nhưng chưa có đường sao lưu nào tới đó.

Lịch trong ngày — và cái bẫy múi giờ của container

Hình G.7. Lịch bảo vệ dữ liệu trong một ngày, theo giờ Việt Nam.

Việc	Chạy ở đâu	Lịch khai	Lần chạy kế tiếp (đọc từ API lúc biên soạn)
Sao lưu mọi máy	Proxmox (host)	23:30	Thứ Sáu 11/09/2026 23:30
Cắt tỉa bản cũ (prune-job hangngay)	PBS trong CT 201	01:00	Thứ Bảy 12/09/2026 01:00
Thu gom rác kho local	PBS trong CT 201	sat 02:00	Thứ Bảy 12/09/2026 02:00
Kiểm SHA-256 (verify-job hangtuan)	PBS trong CT 201	sun 03:00	Chủ nhật 13/09/2026 03:00
Chụp ổ fast	Host — timer lotus-snap@fast	hourly	Mỗi giờ
Chụp ổ share	Host — timer lotus-snap@share	00/6:10	00:10 · 06:10 · 12:10 · 18:10

NGUY HIỂM · LỊCH CỦA PBS CHẠY THEO GIỜ CỦA CONTAINER, KHÔNG THEO GIỜ CỦA MÁY

Khi dựng xong (sáng 11/09/2026), host chạy UTC+7 nhưng CT 200 và CT 201 chạy UTC. Hệ quả: cắt tỉa 01:00 · thu gom rác 02:00 · kiểm SHA-256 03:00 thật ra rơi vào 08:00 – 10:00 sáng giờ Việt Nam — đúng giờ làm việc, ngược hẳn mục đích dồn việc nặng vào ban đêm cho ổ SMR. Không có thông báo lỗi nào: mọi job vẫn báo OK.

▸ Đã sửa cùng ngày: pct set 200 --timezone Asia/Ho_Chi_Minh, tương tự cho CT 201, rồi khởi động lại proxmox-backup-proxy.

▸ Cách nhận ra: so date trên host với pct exec 201 -- date, và đọc trường next-run của các job trong API PBS thay vì tin chuỗi lịch đã khai.

▸ Container mới tạo từ bản mẫu Debian của Proxmox mặc định chạy UTC — nhớ đặt --timezone ngay lúc tạo.

Proxmox được GHI, nhưng KHÔNG được XOÁ bản sao lưu

Proxmox dùng token pve@pbs!backup để gửi bản sao lưu. Token này chỉ có hai vai trò trên kho local: DatastoreBackup (ghi bản mới, đọc lại để khôi phục) và DatastoreAudit (nhìn thấy kho). Không có quyền cắt tỉa. Kho pbs khai trong Proxmox với prune-backups keep-all=1, việc cắt tỉa do chính PBS làm theo lịch riêng.

ĐÚNG THIẾT KẾ · VÌ SAO ĐÂY LÀ KHÁC BIỆT QUAN TRỌNG NHẤT SO VỚI VZDUMP ĐỔ VÀO THƯ MỤC

File vzdump nằm trong một thư mục thì bất cứ ai ghi được thư mục đó đều xoá được. Bản sao trong PBS chỉ bị cắt qua API, bằng quyền mà Proxmox không có — nên kể cả khi máy chủ Proxmox bị chiếm quyền, lịch sử sao lưu vẫn còn.

Bẫy đã gặp khi nối Proxmox vào PBS	Triệu chứng	Nguyên nhân thật
Chỉ cấp DatastoreBackup	pvesm add báo Cannot find datastore 'local', check permissions and existence!	Vai trò này cho ghi mà không cho nhìn thấy kho; API liệt kê kho trả về rỗng. Phải thêm DatastoreAudit
Cấp quyền cho token nhưng quên người dùng	Y hệt dòng trên	Quyền hiệu lực của token là phần giao giữa quyền của token và quyền của người dùng sở hữu nó ⇒ phải cấp cho cả pve@pbs lẫn pve@pbs!backup

Chống trùng lặp — số đo thật

Đại lượng	Giá trị
Dung lượng đĩa ảo đưa vào	VM 100 (32 GiB) + VM 102 (32 GiB) + CT 200 (0,8 GiB) = 64,8 GiB
Chiếm thật trong kho PBS	21 GB — 9.754 khối
Đối chiếu	Bản vzdump cũ của riêng VM 102: 13 GB
Tốc độ ghi đo được	119 – 146 MiB/s

Hai máy Windows gần giống nhau dùng chung phần lớn khối. Và lần chạy sau PBS chỉ ghi khối đã đổi, trong khi vzdump ghi lại đủ cả tệp mỗi lần — đúng kiểu ghi ổ SMR cần.

G.6 Khôi phục từ PBS

Bản trong PBS hiện ngay trên trang Sao lưu của B43, cùng bảng với bản vzdump cũ — thao tác khôi phục giống hệt Chương 17.

Hình G.8. Trang Sao lưu sau khi sửa: bản sao lưu CT 200 mang đúng tên và chữ container.

Số	Thành phần	Giải thích
①	.bk-head — thống kê	Đếm cả bản trong pbs lẫn bản trong local.
②	#bkNew — Sao lưu ngay…	Như mục 12.1. Ô Lưu vào kho nay có pbs — hình dưới.
③	#200 · container	Bản sao lưu container ghi chữ container cạnh số hiệu và mang đúng tên sharestore-smb. Nhãn máy đã bị xoá chỉ hiện khi máy gốc thật sự không còn — và không hiện khi B43 không hỏi được danh sách máy, vì từ một danh sách hỏng không kết luận được gì.
④	Dòng kho pbs	Cột Dung lượng ghi 32 GB là cỡ đĩa khai báo của máy, không phải chỗ thật chiếm: cả ba bản PBS cộng lại chiếm 21 GB.
⑤	Dòng kho local	Bản vzdump cũ của VM 102 (02/09/2026, 13 GB) — tệp .vma.zst thật.

ĐÚNG THIẾT KẾ · ĐÃ SỬA TRƯA 11/09/2026: NHÃN “MÁY ĐÃ BỊ XOÁ” TRÊN BẢN SAO LƯU CONTAINER

Bản sáng của phụ lục này ghi: dòng CT 200 hiện VM 200 · máy đã bị xoá trong khi CT 200 đang chạy — vì GET /api/backups chỉ hỏi danh sách máy ảo KVM (/qemu). Nay B43 hỏi cả danh sách container (/lxc).

▸ Cùng số hiệu mà khác loại (bản sao lưu của một container, nay số đó là một máy ảo) thì máy gốc đúng là đã mất — nhãn vẫn hiện.

▸ Lộ thêm lúc sửa: nút Khôi phục trên bản sao lưu container luôn hỏng, vì B43 gửi mọi yêu cầu khôi phục tới nhánh máy ảo. Đã sửa — xem hộp thoại ở mục ngay dưới.

Hình G.9. Hộp Sao lưu ngay: ô Lưu vào kho có hai lựa chọn, pbs đứng đầu.

Số	Thành phần	Giải thích
①	Ô Lưu vào kho	pbs \| local. Chọn pbs: chống trùng lặp, khác ổ với đĩa máy ảo, Proxmox không xoá được. local nằm chung phân vùng hệ điều hành — xem G.2.

Khôi phục một container — hộp thoại soát trước khi bấm

Container khác máy ảo ở một điểm nguy hiểm: cấu hình của nó có thể trỏ ra ngoài bản sao lưu — bind mount vào thư mục của máy chủ, và địa chỉ IP tĩnh. Bản sao lưu không chứa dữ liệu nào của những thứ đó, chỉ chứa dòng cấu hình. Hộp thoại khôi phục đọc cấu hình trong bản sao lưu ngay khi mở, trước khi ai bấm gì.

Hình G.10. Khôi phục bản CT 200 thành container mới: hộp thoại liệt kê những gì container mới sẽ mang theo.

Số	Thành phần	Giải thích
①	Ô Khôi phục thành	Container MỚI (an toàn — giữ nguyên container hiện tại) hoặc Ghi đè lên chính #200. Lựa chọn ghi đè chỉ có khi container gốc còn.
②	Ô Nơi đặt ổ đĩa	Chỉ liệt kê kho chứa được ổ gốc của container (nội dung rootdir): vmstore, local-lvm.
③	Khung Container mới sẽ mang theo	Với bản CT 200 lúc 02:25: mp0 gắn thẳng /mnt/share, mp1 gắn thẳng /mnt/fast — container mới sẽ ghi chung thư mục với CT 200; IP tĩnh 10.77.0.10 trùng CT 200.
④	Nút Khôi phục	Vẫn bấm được. Có cảnh báo thì B43 khôi phục nhưng không tự bật container, tắt tự khởi động cùng máy chủ và cấp địa chỉ MAC mới. Người vận hành sửa Cấu hình rồi mới bật.
⑤	Nút Huỷ	Đóng hộp thoại, không gửi lệnh nào.
⑥	Dấu ×	Như nút Huỷ.

Hình G.11. Chuyển sang Ghi đè: hộp thoại liệt kê từng mountpoint sẽ quay về bố cục của lúc sao lưu.

Số	Thành phần	Giải thích
①	Ô Khôi phục thành = Ghi đè	Thao tác phá huỷ — backend đòi xác nhận riêng, không suy từ số hiệu.
②	Cảnh báo XOÁ SẠCH	Container #200 hiện có bị xoá rồi dựng lại; mọi thay đổi sau lúc chụp mất.
③	Khung Cấu hình sẽ quay về lúc chụp	mp0: bản sao lưu /mnt/share,mp=/srv/share — hiện tại /mnt/share/data,mp=/srv/share. mp1 tương tự. mp2, mp3 (hai thư mục ảnh chụp chỉ-đọc) không có trong bản sao lưu.
④	Nút Khôi phục	Ghi đè có cảnh báo thì cũng không tự bật lại container.

Đã khôi phục thử thật — không chỉ tin rằng bản sao lưu dùng được

Ngày 11/09/2026, bản sao lưu CT 200 trong PBS được khôi phục thành một container tạm CT 299 trên local-lvm: 15 giây. Kiểm bên trong bản khôi phục: có tài khoản lotus, smb.conf mang dòng server string = Lotus Share, có smbd. Sau đó xoá CT 299. Trước khi xoá, các dòng bind mount được gỡ khỏi cấu hình của CT 299 để lệnh xoá không thể chạm tới dữ liệu ổ chung.

Lần thử thứ hai, trưa cùng ngày, chạy qua chính B43 sau khi sửa: khôi phục bản CT 200 thành CT 299 trên local-lvm. Kết quả: tác vụ OK, container nằm ở trạng thái tắt, onboot: 0, MAC BC:24:11:41:96:84 khác MAC của CT 200, giữ chế độ unprivileged. CT 299 được xoá sau khi chốt đúng tên máy, ổ gốc và trạng thái; kiểm lại sau đó /mnt/share/data còn nguyên — lệnh xoá container không đụng tới nguồn của bind mount.

NGUY HIỂM · KHÔI PHỤC CONTAINER SẼ MANG THEO MOUNTPOINT CỦA LÚC SAO LƯU

Bản CT 200 lúc 02:25 ngày 11/09/2026 được chụp trước khi tách thư mục data / snap: nó chỉ có mp0 = /mnt/share và mp1 = /mnt/fast — gốc của cả khối, gồm luôn thư mục ảnh chụp. Lúc khôi phục thử, lệnh gỡ mp2, mp3 báo not set in current configuration chính vì thế.

▸ Khôi phục ghi đè CT 200 từ bản đó ⇒ Samba sẽ phục vụ cả thư mục ảnh chụp, ở chế độ ghi được.

▸ ⇒ Sau mọi lần khôi phục CT 200: đối chiếu mp0 … mp3 với bảng mountpoint ở G.4 trước khi bật.

▸ Từ trưa 11/09/2026 hộp thoại khôi phục của B43 liệt kê đúng những dòng lệch này trước khi bấm, và không tự bật container sau khi khôi phục.

▸ Các bản tự động từ 23:30 ngày 11/09/2026 trở đi mang cấu hình mới.

Mở giao diện web của PBS

PBS chỉ có địa chỉ trên cầu nội bộ, nên máy bàn không mở thẳng được — đó là chủ ý. Mở bằng đường hầm SSH qua node (đã kiểm: trả HTTP 200):

ssh -L 18007:10.77.0.20:8007 root@172.16.30.102

# rồi mở trình duyệt: https://127.0.0.1:18007

# node dời site thì đổi 172.16.30.102 theo địa chỉ mới của node

G.7 Dung lượng trên ổ 4 TB — đã cấp hết, đổi cỡ về sau phải tắt dịch vụ

Hai khối trên ổ 4 TB được dựng bằng LVM, không phải phân vùng thô — chính để trả lời được câu “sau này thiếu chỗ thì nới được không”. Lúc dựng, nhóm hdd4t giữ lại 250 GiB chưa cấp. Trưa 11/09/2026, theo quyết định của người vận hành, phần đó được cấp hết qua hai bước — cả hai chạy trực tuyến, Samba và PBS không phải dừng:

Bước	Lệnh	Kết quả	Thời gian
Nới share cho tròn 3 TB	lvextend -L 3080G hdd4t/share rồi resize2fs	share 2976 → 3080 GiB; hệ tệp 3,0007 TiB; chưa cấp 250 → 146 GiB	0,2 s + 8 s
Nhập nốt vào pbs	lvextend -l +100%FREE hdd4t/pbs rồi resize2fs	pbs 500 → 646 GiB (B43 ghi 491 → 635 GB); chưa cấp 146 → 0	0,2 s + 3,6 s

GHI CHÚ · VÌ SAO 3080 GIB MÀ KHÔNG PHẢI 3072 GIB (ĐÚNG 3 TIB)

B43 và Windows Explorer đếm theo 1024 dù ghi chữ TB. ext4 giữ khoảng 0,24 % dung lượng cho bảng inode và nhật ký, nên khối đúng 3072 GiB chỉ ra hệ tệp khoảng 3065 GiB — Explorer sẽ ghi 2,99 TB. Khối 3080 GiB cho hệ tệp 3 299 264 110 592 byte = 3,0007 TiB.

▸ Theo cách đếm của hãng ổ (1 TB = 1000 GB), share đã là 3,3 TB từ trước khi nới.

▸ df -h ghi 3.1T vì nó làm tròn lên.

root@pve-001:~# lvs -o lv_name,lv_size,seg_count,devices hdd4t

LV LSize #Seg Devices

pbs <646.02g 2 /dev/sdc1(0)

pbs <646.02g 2 /dev/sdc1(916480)

share <3.01t 1 /dev/sdc1(128000)

Nếu sau này phải đổi cỡ

# Ví dụ: lấy bớt chỗ của share cho pbs

pct stop 200 # Samba đang dùng share

umount /mnt/share

lvreduce -r -L 2980G hdd4t/share # -r: kiểm lỗi + co HỆ TỆP trước, rồi mới co khối

mount /mnt/share && pct start 200

lvextend -r -l +100%FREE hdd4t/pbs # nới pbs — chạy được khi PBS đang chạy

NGUY HIỂM · ĐỪNG CHẠY LVREDUCE THIẾU -R

lvreduce không có -r cắt khối trước khi hệ tệp biết mình nhỏ đi — phần cuối hệ tệp rơi ra ngoài khối, dữ liệu nằm ở đó mất.

▸ Quy trình trên là cách chuẩn của LVM + ext4, chưa chạy thử trên máy này.

Tình huống	Làm được không	Vì sao
Nới pbs hoặc share	Được, nhưng phải co khối kia trước, lúc dừng dịch vụ	Nhóm hdd4t không còn extent trống; LVM chỉ gán lại extent, không dời dữ liệu
Nếu đã dựng bằng phân vùng thô, pbs nằm trước share	Gần như không	Phải co share từ đầu của nó — dời từng khối của gần 3 TB trên ổ SMR
Nếu share đổi sang XFS	Nới được, co không được — vĩnh viễn	Mâu thuẫn với phương án co share để nới pbs

G.8 Phân mảnh — có cần chống không

Nơi	Đo được	Kết luận
Phân vùng hệ điều hành / (ext4, ~2 năm chạy)	e4defrag -c /: điểm 0 · 95.064 / 93.852 extent (dôi 1,3 %)	Không cần. ext4 cấp phát theo extent và hoãn cấp phát tới khi biết cỡ file
Ổ sdc (SMR)	Mới dựng	Không bao giờ chạy e4defrag. Giữ dưới 80 % đầy, cho ổ có giờ rảnh
Ổ sdd (CMR)	Mới dựng	Theo luật ext4 thường; chỉ chạy khi -c báo điểm cao và ổ chưa đầy
Đĩa máy ảo Windows trên vmstore	Cả ba máy khai sata0 thiếu discard=on và ssd=1	Windows tưởng là ổ cơ nên tự chống phân mảnh hằng tuần; khối cũ không được trả lại bể thin. Chưa sửa tại ngày biên soạn

# Lệnh sửa (có hiệu lực sau khi TẮT HẲN rồi bật lại máy, không phải khởi động lại mềm)

qm set 103 --sata0 vmstore:vm-103-disk-0,size=32G,discard=on,ssd=1

G.9 Đã kiểm chứng qua một lần khởi động lại và dời site thật

Sáng 11/09/2026 node được dời từ WP1 sang WP3 và khởi động lại lúc 09:51. Không ai can thiệp; kiểm lúc 10:24:

Thành phần	Sau khởi động lại
Ba khối /mnt/pbs, /mnt/share, /mnt/fast	Tự gắn từ /etc/fstab (có nofail)
CT 200 sharestore-smb, CT 201 pbs	Tự chạy (onboot 1)
Cầu vmbr1, luật NAT, ip_forward	Có đủ — nằm trong /etc/network/interfaces và /etc/sysctl.d/
10.77.0.10:445 (SMB), 10.77.0.20:8007 (PBS)	Mở — cùng địa chỉ dù LAN đã đổi sang 172.16.30.x
Kho pbs trên Proxmox	active
Timer lotus-snap@fast, lotus-snap@share	Chạy tiếp; không có bản chụp nào trong thời gian máy tắt

G.10 Việc còn lại tại ngày biên soạn

Việc	Vì sao cần
Tầng 2: đưa bản sao lưu ra ngoài máy (NAS hoặc một PBS thứ hai)	Hiện chết node là mất tất cả — G.5
Quyết ext4 hay XFS cho share	Chi phí ảnh chụp hardlink — G.4, G.7
discard=on,ssd=1 cho đĩa ba máy ảo Windows	Bể thin chỉ phình không co — G.8

Hai việc của bản sáng đã xong trưa 11/09/2026: trang Hạ tầng thấy được ổ chung và dòng pbs có Loại ổ, Health (G.3); trang Sao lưu nhận đúng container và khôi phục được nó (G.6). Việc thứ ba xong 12/09/2026: ô tích Ổ chung đã làm và kiểm trọn vòng trên máy thật — hai ô F: và S: dùng chung một card mạng, xem mục 10.3, Khối 5.

Phụ lục H — Những bẫy đã trả giá — đợt 15–18/09/2026

GHI CHÚ · PHỤ LỤC NÀY ĐỂ LÀM GÌ

Mỗi mục dưới đây là một lần đã sai thật — hoặc một kết luận vội, hoặc một đoạn mã chạy trót lọt mà cho số sai. Điểm chung của gần như tất cả: không có gì báo lỗi, con số ra trông rất hợp lý, và chỉ lộ ra khi đem đo thay vì đọc chú thích trong mã.

▸ Các chương trước nói hệ thống làm gì; phụ lục này nói vì sao nó làm đúng cách ấy — để người sửa sau không vô tình gỡ một chốt chặn đã được dựng có lý do.

H.1 Nhiệt độ và quạt của pve-001

Ngày 14/09/2026 có một bản ghi kết luận “quạt luôn 100 %, tản nhiệt hỏng”. Đo lại ngày 15/09 cho thấy kết luận đó sai — số đo cũ đúng, nhưng đều lấy lúc máy đang nóng rồi suy ra thành trạng thái thường trực.

Lúc đo	Nhiệt pkg0 / pkg1	PWM quạt 1 / 2	Vòng quay
Đang tải	70 / 84–85 °C	255 / 255	1685 / 1776 RPM
Rảnh thật (tải 0,02)	43 / 47 °C	205 / 194	1450 / 1437 RPM

PWM đổi theo nhiệt ⇒ quạt đang tự điều khiển đúng. Thí nghiệm chốt (15/09, 22:25–22:30): nạp cùng một tải một nhân, 90 giây, lần lượt từng socket.

Nạp tải ở	Nền	Đỉnh	Mức tăng
Socket 0 (cpu0)	44 °C	79 °C	+35 °C
Socket 1 (cpu22)	49–52 °C	85 °C	+33…36 °C

Cảm biến	Dùng được?	Ghi chú
coretemp — Package id 0/1, từng nhân	Có	Số thật, chính xác. Đây là số trên thẻ và đồ thị.
PECI Agent 0/1	Có, cẩn thận	Đọc cao hơn package đều +5/+6 °C. Ghép PECI0 ↔ pkg0, PECI1 ↔ pkg1; ghép chéo là ra kết luận sai.
AUXTIN0 / AUXTIN3 (nct6779)	Chỉ để tham khảo	23 / 29 °C, không nhúc nhích khi CPU nóng ⇒ cảm biến môi trường, không phải VRM.
CPUTIN, SYSTIN, AUXTIN1/2, PCH_*	Không	Chân không nối hoặc đứng im (CPUTIN 127 °C). B43 tự lọc từ 15/09.
Giá trị rác của cảm biến	Không	Ví dụ đo thật: Sensor 1 max = 65261850 (tức 65 261 °C). B43 bỏ mọi số ngoài khoảng 0–150 °C (_mili_sang_do).
VRM	Không đo được	Bo không có BMC/IPMI; mạch điều áp analog. Không dò mù i2c trên máy production — ghi nhầm vào EEPROM SPD là mất thanh RAM.

LƯU Ý · BẪY ĐO ĐÃ VẤP HAI LẦN

Nhiệt và tải phải đo trong cùng một lượt SSH, sau khi máy đã rảnh thật vài phút. Đo nhiệt ở lượt này, tải ở lượt sau thì tải đã tắt mà chip còn đang nguội ⇒ kết luận “nóng trong khi rảnh”.

H.2 Nhịp lấy mẫu và bộ đệm

Trước 16/09/2026, trang Hạ tầng có ba đồng hồ chạy tự do (nhiệt 8 giây, GPU 15 giây, bộ đệm /api/nodes 10 giây) nên mỗi ô số là ảnh chụp của một thời điểm khác nhau. Nhịp chung (mục 2.6) gom chúng lại. Trên đường làm, bốn bẫy lộ ra:

Bẫy	Triệu chứng đo được	Cách chữa
Bộ đệm có ttl bằng đúng nhịp gọi	/api/nodes @cached(ttl=10) cạnh nhịp giao diện 10 giây: hai đồng hồ trôi qua nhau, nhịp nào rơi trúng lúc bộ đệm còn hạn là mất mẫu. Khoảng cách thật giữa các mẫu: trung bình 19 giây, trong khi mọi chú thích trong mã ghi 10.	Lấy mẫu ở chỗ có ttl nhỏ hơn hẳn nhịp. Đo lại: 10,0 giây/mẫu. TTL không bao giờ bằng nhịp.
Tab trình duyệt bị ẩn vẫn gọi API	Trình duyệt không dừng setInterval khi tab ẩn, chỉ bóp còn ~1 lần/phút — và mỗi lần đó vẫn đánh dấu đang xem. Nhịp đo được 10, 10, 10, 30 trông như lỗi, hoá ra là một tab không ai nhìn.	if (document.hidden) return; + nghe visibilitychange.
Lời gọi của chính luồng nhịp tự đánh dấu đang xem	Luồng tự nuôi mình, chạy 10 giây mãi mãi kể cả khi không ai mở trang.	fresh=True không bao giờ đánh dấu đang xem.
Luồng nền chỉ ghi nhiệt gộp	Đồ thị một đường xám dài rồi mới tách làm hai socket ở mấy phút cuối.	Ghi cả goi (từng socket). Số gộp không tách ngược được nên đoạn lịch sử cũ để trống.

Thêm hai điều về lưu trữ mẫu: bảng node_mau có khoá (node, ts) và ghi bằng ON CONFLICT … DO UPDATE … COALESCE — nhiệt và GPU cùng mốc gộp vào một dòng, nguồn nào thiếu số thì không xoá số nguồn kia; và cột mới được thêm bằng ALTER TABLE lúc khởi động, nên metrics.db cũ vẫn dùng tiếp, không phải xoá.

GHI CHÚ · QUY TẮC RÚT RA

Sửa gì đụng tới nhịp lấy mẫu thì đo khoảng cách thật giữa các mẫu trong cơ sở dữ liệu, đừng tin hằng số trong mã. Và trước khi kết luận về nhịp, kiểm nhật ký xem có ai đang gọi API không.

H.3 Tạm dừng — những chốt chặn và lý do của chúng

Sơ đồ hai đường Tạm dừng ở mục 10.3. Bảng dưới là các bẫy đã dựng lại được trên máy thật, và chốt chặn tương ứng trong B43.

Bẫy	Đã xảy ra thế nào	Chốt chặn trong B43
Để Proxmox tự chọn kho trạng thái	Proxmox chọn kho local — kho này không có content images. Ghi tệp trạng thái được, nhưng lúc bật lại chết với storage 'local' does not support content-type 'images' và máy kẹt lock: suspended. Phải gỡ tay: qm unlock + qm set --delete vmstate + xoá tệp.	Luôn tự chọn và truyền statestorage: ưu tiên kho ổ đĩa của máy, kiểm có images và đủ chỗ.
Tính thiếu chỗ	Tệp trạng thái cần RAM × 2 + 500 MB (đo: máy 512 MB ⇒ 1 598 029 824 byte).	Kiểm chỗ trống trước khi gửi lệnh; thiếu thì từ chối kèm con số.
Bật lại bằng status/resume	resume dành cho máy đang pause trong RAM, không phải máy đã ghi ra đĩa.	Nút Chạy tiếp gọi status/start — qm start tự nhận ra lock: suspended.
Máy có vGPU	Proxmox chặn cứng todisk khi có PCI passthrough; không cờ nào vượt được, kể cả skiplock.	Đi đường ngủ đông trong Windows (shutdown /h).
Card vẫn bật lúc ngủ đông	VM 103: nhật ký Windows ghi 42 (vào giấc) rồi 41 + 6008 — khởi động lại bẩn.	Disable-PnpDevice card trước shutdown /h, bật lại sau khi thức. Đo lại: 42 → 107 (thức đúng).
Thiếu enable-s4=1 trong machine	QEMU không khai S4 trong ACPI: powercfg /hibernate on chạy trót lọt mà Windows vẫn báo firmware không hỗ trợ — dù ổ C: còn 13,2 GB. Đổi machine chỉ ăn sau một lần Tắt rồi Bật thật.	Kiểm cờ trước; báo đúng lý do, không nói hết chỗ.
Fast Startup còn bật	Bật S4 thì Fast Startup xuất hiện và dùng chung cơ chế ngủ đông.	Tắt Fast Startup khi bật Tạm dừng cho máy vGPU.
powercfg /a để dò ngủ đông	Chữ Hibernate in ở cả khối available và not available ⇒ phép dò luôn đúng. VM 100 (không bật) cho kết quả y hệt VM 103 (có bật).	Đọc registry HibernateEnabled và đòi hiberfil.sys có thật.
Get-Item C:\hiberfil.sys -Force	Trả NULL dù tệp có thật (hệ thống khoá tệp).	Get-ChildItem C:\ -Force -Filter hiberfil.sys — chỉ duyệt thư mục nên đọc được: 3 435 753 472 byte.
Proxmox không biết máy vGPU đang ngủ	Sau shutdown /h, Proxmox chỉ thấy stopped, không có lock/vmstate.	B43 tự nhớ trong /data/ngu_dong.json để nút đổi thành Chạy tiếp và uptime cộng dồn.

LƯU Ý · VÌ SAO TẠM DỪNG MẶC ĐỊNH TẮT

Đường ngủ đông giữ hiberfil.sys vĩnh viễn trên ổ C: của máy khách (VM 103, 8 GB RAM: 3,20 GB; tick ⇒ ổ C: còn trống 12,9 → 9,7 GB). DŨNG chốt ngày 16/09/2026: chỉ máy nào người dùng tick mới được Tạm dừng. Dấu nằm ở tag b43-tam-dung trong cấu hình máy — đi theo máy, mất cùng máy.

H.4 Các bẫy khác trong đợt

Chỗ	Bẫy	Đúng là
Cổng USB — ACPI	Bo HUANANZHI X99-T8D khai ACPI _PLD rác: cả 22 cổng đều panel=top, connect_type=hardwired. Lọc theo hardwired là ẩn sạch mọi cổng.	Chỉ đọc ra cho biết, không lọc, không xếp nhóm theo ACPI. Muốn biết lỗ nào là cổng nào thì cắm thử.
Cổng USB — PCI	Card khai ở hostpci0 là 0000:81:00.0, bộ điều khiển USB của chính nó là 0000:81:00.2. So nguyên chuỗi thì sáu cổng USB-C trên card vẫn được mời gán.	So địa chỉ PCI phải cắt phần .hàm.
Cổng USB — định danh	Đánh số lại thành USB0/USB1 theo thứ tự hiển thị: cắm thêm một thiết bị là mọi cổng sau tụt một bậc.	Giữ đường cổng vật lý 3-4; sắp xếp theo số (3-9 trước 3-10). Proxmox không chặn hai máy cùng khai một cổng ⇒ B43 quét toàn node trước khi gán.
app/main.py — decorator	Endpoint khai trước chỗ định nghĩa cached (~dòng 800) mà dùng @cached ⇒ NameError lúc nạp module ⇒ container vòng restart. py_compile không bắt được. Đã dính thật 18/09 với /api/tac-vu.	tests/test_cau_truc.py quét AST và nêu đúng tên hàm + dòng. Chạy bộ test trước mọi lần restart.
API /cluster/backup	prune-backups là dict khi GET nhưng phải gửi chuỗi; id không tồn tại trả 500 chứ không phải 404; đổi phạm vi phải kèm delete=all\|vmid\|pool; không có endpoint chạy ngay.	B43 tự chuyển kiểu, tra danh sách trước khi hỏi từng id, gửi delete= khi đổi phạm vi, và Chạy ngay là POST /nodes/{n}/vzdump với đúng tham số của lịch.
Huy hiệu màu	Chữ --status-X trên nền --status-X-bg: vàng trên vàng chỉ đạt 1,93 : 1 (đo 17/09).	Dùng token chữ riêng --status-X-fg; không dùng opacity để làm nhạt chữ.
Kiểm giao diện bằng Selenium	d.get() tới cùng hash đang mở không vẽ lại trang; scrollIntoView mặc định đặt phần tử dưới thanh trên cùng (sticky) nên bấm trúng thanh.	location.reload() sau khi đổi trạng thái; scrollIntoView({block:'center'}).

Phụ lục I — Đối chiếu với DigitalOcean và VMware vSphere — và những gì đã chốt

GHI CHÚ · NGUỒN VÀ THỜI ĐIỂM

Tóm tắt từ B43_Lotus_Cloud/docs/danh-gia-so-voi-do-vmware.md, viết ngày 18/09/2026 trước đợt bổ sung cùng ngày. Bản gốc có bảng có/không đầy đủ cho tám nhóm chức năng; phụ lục này chỉ giữ phần dẫn tới quyết định.

▸ Con số kiểm kê trong bản gốc (82 endpoint, 10 trang) là của trước đợt bổ sung. Số hiện tại: 119 endpoint, 12 trang (Phụ lục D, mục 1.4).

I.1 Ba sản phẩm, ba việc khác nhau

	DigitalOcean	VMware vSphere	B43 Lotus Cloud
Bán cho ai	Lập trình viên thuê máy công cộng	Phòng IT doanh nghiệp	Một người vận hành cụm riêng
Quy mô	Không giới hạn, phần cứng bị giấu	Cụm nhiều node, vCenter	Máy chủ Proxmox riêng, khoảng 5–10 máy ảo
Thế mạnh	Thanh toán, đội nhóm, cân bằng tải, DNS	Di chuyển nóng, tự phục hồi, phân quyền tinh	Chạm được phần cứng: nhiệt, vGPU, USB, ổ vật lý

Vì vậy “không có” chưa chắc là “thiếu”. Một tính năng chỉ tính là thiếu khi cụm này thật sự cần và Proxmox làm được.

I.2 Những gì B43 có mà cả hai đều không có

DigitalOcean không có vì không cho thấy phần cứng; vSphere có một phần nhưng rải ở ba nơi (vCenter, trang quản trị từng máy chủ, IPMI) chứ không cùng một trang.

I.3 Đề xuất và quyết định

Bản đánh giá xếp các việc có thể làm theo giá trị cho cụm này chia cho công sức. Bảng dưới ghi kết quả sau ngày 18/09/2026.

Nhóm	Việc	Kết quả	Ở đâu trong sách
A1	Xác thực hai lớp TOTP	Đã làm 18/09 — DŨNG đã bật	Mục 6.1, 15.3
A2	Cảnh báo chủ động	Đã làm 18/09 — Telegram, webhook; Slack thêm 19/09	Mục 15.5
A3	Lịch sao lưu trong bảng điều khiển	Đã làm 18/09	Mục 12.1
A4	Nhật ký thao tác + lịch sử tác vụ Proxmox	Đã làm 18/09	Mục 15.4
B1	Token API quyền hẹp thay mật khẩu root	DŨNG chốt không làm	—
B2	Ổ đĩa rời gắn / tháo / chuyển máy	DŨNG chốt không làm — ổ chung Samba đã phủ nhu cầu	Phụ lục G
B3	Nhiều card mạng · VLAN · giới hạn băng thông	DŨNG chốt không làm	—
B4	Tường lửa từng máy	DŨNG chốt không làm — router ER605 lọc biên	—
C1–C4	Nhiều người dùng · thêm CPU/RAM nóng · di chuyển máy giữa node · tạo hàng loạt	Chỉ làm khi hoàn cảnh đổi (có người vận hành thứ hai, máy không được phép tắt…)	—
—	Gửi cảnh báo qua Zalo	DŨNG chốt không làm: Zalo chỉ có API chính thức cho Official Account; không dùng bản Zalo không chính thức	—

GHI CHÚ · NHỮNG THỨ KHÔNG LÀM VÌ KHÔNG KHẢ THI HOẶC VÔ NGHĨA VỚI CỤM NÀY

Tự phục hồi / cân bằng tài nguyên / chịu lỗi tức thời (cần từ ba node trở lên để bỏ phiếu) · cân bằng tải · DNS · IP nổi · mạng ảo riêng (VPN giữa các site đã cô lập) · thanh toán · Kubernetes · đa ngôn ngữ · mã hoá đĩa.

▸ Về VMware: từ 2024 vSphere chỉ còn thuê bao theo nhân, tối thiểu 16 nhân mỗi CPU, và các tính năng cụm đều đòi vCenter trả phí. Với 2 × 22 nhân của pve-001 thì đó không phải lựa chọn — và dùng bản không bản quyền là điều đã loại từ đầu.

I.4 Rà lại thành phần cũ

Cùng bản đánh giá có rà lại các thành phần đã chạy từ trước. Hiệu năng không có gì đáng lo; phần đáng sửa là độ tin cậy, và đã sửa trong đợt 18/09 (mục 2.7, bảng Bản cập nhật ở đầu sách):

Thành phần	Số đo 18/09/2026	Kết luận
Tài nguyên container	111 MB RAM, 0,2 % CPU lúc rảnh	Không có gì để tối ưu.
Tốc độ API	Lần đầu 0,7–1,5 giây; khi bộ đệm ấm 7–20 ms	Giữ nguyên thiết kế bộ đệm.
Tệp tĩnh	710 KB mỗi lần tải, không nén	Đã sửa: nén gzip (mục 2.7).
Kiểm thử tự động	0 test	Đã sửa: bộ test hai tầng trong tests/ (mục 2.7).
Tệp trạng thái trong /data	9 tệp ghi nguyên tử, sshkeys.json ghi thẳng	Đã sửa: mọi tệp ghi tạm rồi đổi tên.
Huy hiệu .hp-warn	Tương phản 1,93 : 1	Đã sửa 18/09 (H.4).
Kích thước mã	main.py 9 578 dòng, app.js 8 821 dòng	Nợ thật, nhưng không tách đại trà — tách dần khi chạm tới.