物理服务器虚拟化分片：VPS架设全流程与运维实践

手上有台物理服务器，却不知道该怎么分给几个人用——这场景我碰到太多次了。机器买回来或者托管在机房，跑单一业务绰绰有余，可一旦要同时跑测试环境、预发布环境、几个内部小站，全塞进一套系统里迟早出事：某人装错一个包，另一个人的服务直接起不来；某个脚本把 CPU 吃满，整台机器跟着卡死。这时候 VPS 架设就成了刚需——把一台物理机切成若干台互相看不见、各自有独立系统盘的虚拟专用服务器，谁的系统谁负责，出问题只影响自己那一台。

这篇东西讲的就是这件事的完整落地过程：从一台裸机开始，怎么规划资源、怎么选虚拟化路线、怎么用现成平台或者纯命令行把 VPS 一台台开出来、怎么交付给使用者、后面怎么盯住不出事。要说清楚边界，这里讲的是在你自己可控的硬件上做虚拟化分片，面向的是建站、开发测试、CI 构建机、内部服务、教学实验环境这类用途，跟去服务商那儿买一台现成主机是两回事。适合的读者也很明确：手上有物理机或托管机、会敲基本 Linux 命令、想把资源切开分给多个人或多种环境用的运维、独立开发者、小团队负责人。完全没碰过 Linux 的也不用急着关页面，第二、三章我会把前置条件交代清楚，照着做能跑通。

1. 先把账算清楚：VPS 到底该用什么方式切

1.1 从"一台机器一件事"到"一台机器多租户"

物理服务器最朴素的使用方式就是装一套系统、跑一组服务。这种模式在早期没问题，但随着业务变复杂，麻烦会集中爆发在三个地方。第一个是依赖冲突：A 项目要 Python 3.8，B 项目要 3.11，同一套系统里来回切换，早晚出乱子。第二个是故障扩散：一套系统里任何一个进程把内存吃干净，OOM Killer 挑谁下手全看运气，可能把最关键的服务干掉。第三个是权限边界：把 root 给出去谁都不放心，不给又干不了活。

VPS 的思路本质上是把这三个问题用"隔离"一次性解决。每台 VPS 有自己的内核态（KVM 路线）、自己的文件系统、自己的网络栈、自己的 root 账号。使用者在自己那台里怎么折腾都行，删库重装都无所谓，宿主和其他 VPS 不受影响。我给一个内部团队做过这种改造，之前他们的测试环境是"一台机器上开五个目录"，改完之后每个环境一台 VPS，重建环境从半天缩短到三分钟，方法就是把做好的模板克隆一份。

理解这一点很重要，因为它决定了后面所有的技术选型都围绕"隔离强度"和"资源开销"这两个维度做权衡，而不是简单地比谁装得快。

1.2 三条虚拟化路线的取舍

真要动手，绕不开的选择就三种：全虚拟化（KVM/QEMU 这一类）、容器化（LXC/LXD 这一类）、以及混合方案。很多人一上来就问"哪个好"，这问题没答案，得看你要交付什么。

我个人的默认选择是混合：对外的、要给 root 的、可能跑不同发行版的，一律上 KVM；内部 CI 构建机、临时压测环境这种用完就删的，用容器更划算，一台 64GB 内存的机器用容器能塞三四十个构建节点，用 KVM 可能就二十出头。

这里有个常被忽略的点：容器共享宿主内核，意味着宿主内核一升级，所有容器跟着受影响；某台容器里如果触发了内核 bug，理论上可能波及宿主。所以只要这台 VPS 的使用者不完全可控，就别图省内存用容器，省下的那点内存，出事时赔进去的时间远不止。

1.3 资源超卖的边界与容量规划

买服务器的时候销售会告诉你"64 核 128G，能开 60 台 VPS"，这话只能听一半。真实能开多少台，取决于你愿意接受多高的超卖比，以及使用者的负载特征。

先把宿主的开销扣掉。虚拟化平台本身、监控、备份进程、日志，加起来预留 2–4GB 内存和 2 个核是稳妥的。剩下 124GB，如果每台 VPS 给 4GB，账面是 31 台。

但内存不能按账面开。看使用者的实际峰值：如果是开发测试机，P95 内存占用通常只有分配量的 40%–60%，这种情况下 1:1.5 的超分是安全的；如果是对外提供服务的机器，峰值可能贴着上限跑，那就老老实实 1:1，别超。

CPU 相对宽松，因为绝大多数时间在等 IO。经验值是 1:3 到 1:4 的 vCPU 超分比，前提是你给每台配了合理的 CPU 限额（cgroup 或 KVM 的 cpu shares），避免某一台把物理核全占满。

磁盘是最容易翻车的地方。用了 thin provisioning（精简置备）之后，你给 30 台各分 100GB，账面 3TB，实际写入可能只有 800GB，看起来很美好。但只要有几台同时写满，存储池一爆，所有 VPS 一起挂。我的做法是留 25% 的富裕空间，并且在监控里对存储池使用率设 70% 的告警线，到线就停下来处理，而不是等它自己撑爆。

提示：容量规划做完之后，把"账面数"、"实际可开数"、"告警阈值"三个数字写进文档。后面加机器、加人的时候，这三行字能救你。

2. 硬件与系统底座的准备

2.1 硬件选型与磁盘布局

VPS 宿主对硬件的偏好跟普通业务机不太一样。CPU 核心数比单核主频更重要，因为你要切的是"核数"；内存容量直接决定能开几台，是最该堆的部件；磁盘看的是 IOPS 和随机写性能，而不是容量。

磁盘这一块我踩过大坑。早期用两块机械盘做 RAID1，开了十几台 VPS 之后，只要有两台同时在编译代码，全盘的 IO 延迟直接冲到几百毫秒，所有 VPS 都卡成幻灯片。换成 SSD 之后立刻正常。条件允许的话，企业级 SSD 做 RAID10（至少四块盘），预算紧就两块 NVMe 做 RAID1，别用单盘，单盘一坏所有 VPS 全没。

文件系统层面有两个常见选择：LVM-thin 和 ZFS。LVM-thin 成熟、性能损耗小、快照和精简置备都支持，缺点是快照多了之后碎片化明显，回收空间需要手动 fstrim。ZFS 功能更全，压缩、校验、快照、发送接收一应俱全，代价是吃内存（建议每 TB 配 1GB ARC）并且写放大会消耗 SSD 寿命。我的取舍是：盘多、内存富余、需要定期异地备份的，用 ZFS；盘少、内存紧、只追求性能的，用 LVM-thin。

2.2 系统安装与基础加固

宿主系统我一般选 Debian 稳定版或者对应的服务器发行版，理由很简单：包版本保守，不会三天两头给你推大更新，跑几年不出幺蛾子。安装时只装最小系统，不加桌面环境，能少一个包就少一个包。

装完第一件事是加固。SSH 改端口、禁密码登录只留密钥、关掉 root 直连，这三步是基本功。然后是防火墙，默认拒绝所有入站，只放行 SSH 和管理端口，其余端口等具体的 VPS 建好之后再按需开。

内核参数要调几项，直接影响多实例下的稳定性：

# /etc/sysctl.d/99-vps-host.conf # 减少 swap 倾向，虚拟化宿主上频繁换页会拖垮所有实例 vm.swappiness = 10 # thin provision 场景下，脏页回写太激进会造成 IO 尖刺 vm.dirty_ratio = 10 vm.dirty_background_ratio = 5 # 提高文件句柄上限，多实例叠加后很容易打满默认值 fs.file-max = 2097152 # ARP 缓存与邻居表，桥接网络下实例多时容易溢出 net.ipv4.neigh.default.gc_thresh1 = 1024 net.ipv4.neigh.default.gc_thresh2 = 4096 net.ipv4.neigh.default.gc_thresh3 = 8192

vm.swappiness调到 10 不是玄学。宿主一旦开始大量换页，磁盘队列会被 swap 写满，所有 VPS 的 IO 一起遭殃，这个连锁反应比单机场景严重得多。至于脏页比例，默认的 20% 在几十个实例并发写的时候会攒出一大波回写，表现为周期性的卡顿，调到 10/5 之后曲线明显平滑。

2.3 网络规划：网桥、独立 IP 与内网段

网络是新手最容易卡住的地方。核心概念只有一个：VPS 要对外提供服务，就得有一个能路由到它的地址。两种做法。

第一种是桥接。宿主建一个网桥vmbr0，把物理网卡挂上去，VPS 的虚拟网卡也挂上去，这样 VPS 就像接在同一台交换机上，直接拿独立 IP。这种方案配置最直观，性能也好，缺点是需要你有多个可用 IP，并且机房那边允许你这么用（有些托管商对 MAC 地址有绑定策略，需要提前报备）。

第二种是 NAT。宿主自己拿一个公网 IP，内部给 VPS 分配 10.x 或 192.168.x 的私网地址，对外服务靠端口映射。IP 不够的时候只能这么干，代价是映射表要维护好，端口冲突得自己协调。

# /etc/network/interfaces 片段（Debian 系，桥接方案） auto vmbr0 iface vmbr0 inet static address 203.0.113.10/24 gateway 203.0.113.1 bridge-ports eno1 bridge-stp off bridge-fd 0

这里有个细节值得说：bridge-fd 0是关掉转发延迟，不写的话新接入的虚拟网卡会有几秒钟学不到 MAC，表现为 VPS 起来之后网络要等一会儿才通，排查起来很费时间。另外桥接模式下宿主自己的防火墙规则要留意，FORWARD 链默认策略如果是 DROP，VPS 的流量会被悄悄拦掉，日志里还看不到明显报错，这个坑我当年找了一整晚。

3. 用现成平台落地：从裸机到可交付 VPS

3.1 平台安装与初始配置

如果你不想从零拼命令行，用一套开源的虚拟化管理平台是最省事的路径。这类平台把 KVM、存储、网络、Web 管理界面打包好了，装完就能在浏览器里点着开机器。我常用的那套基于 Debian，安装过程就是写盘、启动、按向导走。

安装时唯一需要动脑的是磁盘配置。默认会建议用整盘做 LVM-thin 或者 ZFS，如果机器有多块盘，我倾向于系统盘单独一块小 SSD，数据盘另外组池，这样系统重装不影响已有 VPS。

装完之后第一件事是配好存储和网络，然后关掉不必要的服务。管理界面默认走 8006 端口，务必只对管理网段开放，别直接甩在公网上——这类界面的登录入口是自动化扫描的重点目标，暴露出去等于给自己找事。

3.2 存储池与模板制作

这一步是效率的分水岭。手工装一台 VPS 要十几分钟，做完模板之后克隆一台只要二十秒，差别就在这儿。

做法是拿一个官方的 cloud image（各发行版都提供预装好的 qcow2 镜像），导入成模板，然后用 cloud-init 注入初始化配置。以 Debian 系的镜像为例：

# 下载并导入 cloud image 作为模板 wget https://cloud.example.org/debian-12-genericcloud-amd64.qcow2 qm create 9000 --name tpl-debian12 --memory 2048 --cores 2 \ --net0 virtio,bridge=vmbr0 qm importdisk 9000 debian-12-genericcloud-amd64.qcow2 local-lvm qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-9000-disk-0 qm set 9000 --ide2 local-lvm:cloudinit qm set 9000 --boot c --bootdisk scsi0 qm set 9000 --serial0 socket --vga serial0 qm template 9000

几个参数值得解释。--scsihw virtio-scsi-pci配合scsi0用的是 virtio 半虚拟化驱动，磁盘 IO 性能比默认的 IDE 模拟高出数倍，这是必选项不是可选项。--serial0 socket --vga serial0是让控制台走串口，好处是你可以在 Web 界面里直接看到启动日志，机器网络没配通的时候这是唯一的救命通道。--ide2 ...cloudinit挂载的是 cloud-init 的配置盘，后面所有初始化动作都靠它。

3.3 创建第一台 VPS 与自动初始化

模板有了，克隆一台出来并注入配置：

qm clone 9000 101 --name vps-dev-01 --full qm set 101 --cores 4 --memory 8192 qm set 101 --ipconfig0 ip=203.0.113.21/24,gw=203.0.113.1 qm set 101 --ciuser devuser --sshkeys ~/.ssh/id_ed25519.pub qm set 101 --nameserver 203.0.113.2 qm start 101

--full表示完整克隆，会复制一份独立磁盘；不加这个参数是链接克隆，省空间但依赖模板，模板一删机器就废。生产环境我一律用完整克隆，磁盘空间换确定性，值。

--ipconfig0把 IP 直接写进 cloud-init，机器首次启动就自动配好网络，不需要进控制台手敲。--ciuser和--sshkeys同理，开出来就能用密钥登录，密码登录压根不用开。

整个过程从敲命令到能 SSH 进去，实测 25 秒左右。给使用者交付的时候，我把这套命令包成一个脚本，参数化机器名、核数、内存、IP，交给同事自己跑，省掉来回沟通。

3.4 快照、备份与克隆的正确用法

这三样经常被混为一谈，实际上定位完全不同。

快照是某个时间点的磁盘状态，回滚极快，但它跟原盘存在同一存储上，原盘挂了快照一起没。快照只适合"我要改个配置，改坏了想退回去"这种短周期场景，改完确认没问题就该删掉，留着会持续占用空间并拖慢 IO。

备份是独立的一份数据，应该落到另一块盘甚至另一台机器上。备份频率按数据重要程度定，我一般给使用者提供每日增量、每周全量两档，保留两周。备份一定要定期做恢复演练，只备不验等于没备，这话听起来老套，但真到用的时候发现备份文件损坏的例子我见过不止一次。

克隆是纵向扩展的手段：一台机器调好了，要十台一样的，克隆最快。但克隆完记得改主机名、改 IP、重新生成 SSH host key，否则十台机器共用一个 host key，连接时客户端会一直报冲突警告，使用者也分不清自己在哪台机器上。

4. 纯命令行路线：手工拼一套出来

4.1 组件安装与网桥配置

不想装整套平台，或者要在已有的系统里加虚拟化能力，那就自己拼。核心组件就四个：QEMU（模拟硬件）、KVM（内核加速模块）、libvirt（管理接口）、cloud-init（初始化）。

# Debian/Ubuntu 系 apt install -y qemu-system-x86 qemu-utils libvirt-daemon-system \ libvirt-clients bridge-utils virtinst cloud-image-utils systemctl enable --now libvirtd # 验证 KVM 加速是否可用，输出非空才算成功 kvm-ok || lsmod | grep kvm

kvm-ok那一步别跳过。如果宿主是嵌套在别的虚拟机里跑，或者 BIOS 里没开虚拟化扩展，KVM 模块加载不上，QEMU 会退化成纯软件模拟，性能差一到两个数量级，表现为 VPS 慢得不像话但看不出任何报错。这种问题排查起来特别费劲，装完就验证一下最省事。

网桥配置在第二章已经写过，这里补一个常被漏掉的点：宿主的br0拿到 IP 之后，物理网卡eno1本身不应该再配 IP，否则会出现两个地址在同一广播域里打架，表现为间歇性丢包，ping 一会儿通一会儿不通。

4.2 virt-install 参数逐项拆解

virt-install是命令行创建虚拟机的核心工具，参数多但逻辑清晰，理解几个关键的就行。

virt-install \ --name vps-app-01 \ --vcpus 4,sockets=1,cores=4,threads=1 \ --memory 8192 \ --disk path=/var/lib/libvirt/images/vps-app-01.qcow2,size=100,format=qcow2,bus=virtio,cache=none,discard=unmap \ --network bridge=vmbr0,model=virtio \ --os-variant debian12 \ --cloud-init user-data=/root/ci/vps-app-01.yaml \ --graphics none \ --console pty,target_type=serial \ --import

--vcpus 4,sockets=1,cores=4,threads=1这个写法是明确告诉客户机拓扑结构。有些软件（尤其是按 socket 授权或者按 NUMA 优化的）会因为拓扑不对而发挥不出性能，显式写死比让系统自己猜稳。

磁盘参数里的cache=none和discard=unmap是两个关键。cache=none让 IO 绕过宿主页缓存直通磁盘，多实例场景下能避免宿主的缓存被反复冲刷，整体吞吐更好。discard=unmap打开 TRIM 透传，SSD 上长时间运行不做这个设置，删除文件后空间不会真正回收，写性能会逐渐下降。

--os-variant别乱填，它决定的是时钟源和驱动优化策略。填错了轻则性能打折，重则客户机时钟漂移，表现为日志时间戳乱跳、定时任务不准。填之前用osinfo-query os查一下准确的标识。

4.3 一份可复用的创建脚本

把上面的东西整理成脚本，参数化之后交给团队用，是我觉得最值的一步投入。

#!/usr/bin/env bash set -euo pipefail NAME="${1:?用法: ./mkvps.sh <名称> <核数> <内存MB> <磁盘GB> <IP/掩码>}" VCPU="${2}"; MEM="${3}"; DISK="${4}"; IPADDR="${5}" IMAGE="/var/lib/libvirt/images/tpl-debian12.qcow2" POOL="/var/lib/libvirt/images" # 从模板复制一份独立磁盘，用 cp --reflink 在支持的文件系统上是秒级的 cp --reflink=auto "${IMAGE}" "${POOL}/${NAME}.qcow2" qemu-img resize "${POOL}/${NAME}.qcow2" "${DISK}G" cat > "/tmp/${NAME}-user-data.yaml" <<EOF #cloud-config hostname: ${NAME} users: - name: appuser sudo: ALL=(ALL) NOPASSWD:ALL ssh_authorized_keys: - $(cat /root/.ssh/id_ed25519.pub) package_update: false runcmd: - [ systemctl, enable, --now, qemu-guest-agent ] EOF virt-install --name "${NAME}" --vcpus "${VCPU}" --memory "${MEM}" \ --disk path="${POOL}/${NAME}.qcow2",bus=virtio,cache=none,discard=unmap \ --network bridge=vmbr0,model=virtio \ --os-variant debian12 --graphics none --import \ --cloud-init user-data="/tmp/${NAME}-user-data.yaml" \ --noautoconsole echo "${NAME} 已创建，IP 待客户机内配置为 ${IPADDR}"

脚本里cp --reflink=auto这个细节值得一提：在支持 CoW 的文件系统（比如 XFS 开了 reflink、Btrfs、ZFS）上，复制模板几乎是瞬间完成的，不占额外空间，比qemu-img convert快几十倍。在不支持的文件系统上它会自动退化成普通复制，不影响正确性。

qemu-guest-agent也建议装上。它能让宿主知道客户机的真实 IP、文件系统使用率，做优雅关机而不是硬断电。没装这个的话，关机只能靠 ACPI 信号，客户机不响应就只能强杀，久而久之文件系统容易出问题。

5. 交付前的验收与长期运维

5.1 性能基线测试与交付检查清单

机器开出来不等于能交付。我习惯跑一遍基线测试，留个数据存档，后面出问题时有对照。

CPU 用sysbench cpu run看单核和多核分数；磁盘用fio做随机读写，重点看 4K 随机写的 IOPS 和延迟；网络用iperf3测宿主到客户机的带宽，桥接模式下应该接近物理网卡线速，如果只有一半甚至更低，多半是网桥配置或者中断绑核有问题。

# 客户机内执行，4K 随机写基线 fio --name=randwrite --ioengine=libaio --iodepth=32 \ --rw=randwrite --bs=4k --direct=1 --size=1G \ --numjobs=4 --runtime=60 --group_reporting

交付前的检查清单我固定这么几项：

5.2 监控、告警与资源回收

宿主层面的监控必须自己搭起来，别指望使用者反馈。等使用者说"我这台很卡"的时候，通常已经卡了很久了。

我最小的一套组合是：每台 VPS 装 node_exporter，宿主也装，数据进时序库，面板上看四个核心指标——宿主 CPU 使用率、内存可用量、存储池使用率、每台的磁盘延迟。告警线按经验设：存储池 70%、宿主内存可用低于 15%、单台磁盘延迟超过 50ms 持续五分钟。

资源回收是个容易被忽略的活。团队里总有人开了机器用完不关，半年下来能攒出一堆僵尸实例。我的做法是给每台机器打标签，记录创建人、用途、到期时间，每月跑一次清单，到期前一周发提醒，没续期的自动关机保留一周再删。这个流程推行下去之后，存储池的使用率从 85% 降到了 50% 左右，等于凭空多出一批容量。

5.3 多使用者隔离与权限边界

只要 VPS 是给别人用的，权限就得设计。平台层面我给每个使用者建独立账号，只授权到自己名下的那些机器，别给全局管理员。宿主的 root 密码只有两个人知道，这是底线。

网络层面，如果不同使用者的机器之间不该互通，就在网桥上做隔离，或者干脆给他们分到不同的内网段，用防火墙规则隔开。这一点在给外部客户交付时尤其重要，客户 A 的机器能扫到客户 B 的端口，这在合规上是有问题的。

还有一条经验：给使用者开通机器的时候，顺手把默认的 SSH 端口改掉、装上基础的入侵检测和日志审计。不是不信任使用者，而是他们的机器一旦被攻破，攻击者可能拿它当跳板往宿主和其他机器上打，宿主的安全边界会被从内部撕开。KVM 的隔离很强，但前提是宿主自己不敞开大门。

6. 踩坑记录与常见问题排查

6.1 典型故障速查表

这些年攒下来的问题，绝大多数都集中在几个固定位置。整理成表，出问题时先对号入座，能省掉大量瞎试的时间。

6.2 几条用时间换来的经验

第一条是关于快照的。我见过有人把快照当备份用，机器跑了半年攒了二十几个快照，某天存储池满了，所有机器一起挂，因为快照链太长，连删都删不动。快照是临时工具，不是数据保险，这个认知必须在团队里统一。

第二条是关于 IP 规划的。一开始觉得 IP 够用，随便分配，等到要扩机器的时候发现地址段碎得没法整理。我的建议是哪怕现在只有五台机器，也按用途划段：开发段、测试段、生产段分开，每段留足余量并写进文档。改 IP 比一开始就规划好要麻烦十倍。

第三条是关于模板的。模板做完之后一定要在一个干净环境里完整跑一遍：从克隆、启动、注入配置到能登录、能联网、能装包，全流程走通再拿去用。我吃过一次亏，模板里残留了旧机器的 cloud-init 状态，克隆出来的机器全都用了同一个 IP，撞了地址，十几台一起断网，排查的时候先怀疑网络再怀疑路由，最后才发现是模板的问题。

第四条，也是最实在的一条：先把一台机器完整跑顺，再考虑批量。VPS 架设这事看着是"开很多台"，实际上难点全在"第一台"——网络通不通、初始化对不对、性能达不达标，这些问题在第一台上暴露出来，成本最低。等二十台一起开出来再发现问题，返工的工作量是指数级增长的。我现在的习惯是每加一种新配置，都先开一台灰度跑一周，确认没问题再推广，慢一点但省心。