部署KVM时，香港EPYC 7713（64核128线程、25M CN2）如何分配虚拟机资源？

在香港EPYC 7713服务器上部署KVM，不能简单地把64个物理核心、128个逻辑线程和25M线路平均切成若干份。更稳妥的做法是先为宿主机、虚拟化开销、磁盘与网络管理保留资源，再按照业务类型分配固定的vCPU、内存、存储和带宽，并通过监控结果逐步提高利用率。

以下方案按“25M=25Mbps”的常见线路标注方式设计，适用于香港节点上的网站、API、应用服务、数据库、监控和轻量计算任务。示例以256GB内存、Ubuntu Server 22.04/24.04、KVM与libvirt为基准；如果实际内存、磁盘或公网IP数量不同，应按文中的计算方法调整，而不是直接照搬示例数值。

准备条件

1. 明确宿主机与业务边界

EPYC 7713通常提供64个物理核心、128个逻辑线程。128个逻辑线程代表操作系统可调度的CPU线程数量，不等于128个完整物理核心。对于数据库、编译、转码等持续消耗CPU的任务，应优先按物理核心规划；SMT逻辑线程更适合用于Web、API、队列、监控等负载波动较大的业务。

本方案的目标状态如下：

• 宿主机保持稳定运行，不因虚拟机突发负载进入内存回收或CPU争抢。
• 生产虚拟机不在初始阶段过度超售，保留一部分CPU、内存和带宽作为故障缓冲。
• 数据库默认使用固定内存，不依赖气球驱动在宿主机内存不足时强行回收。
• 25Mbps线路以总量管理，避免单台虚拟机占满外联带宽。
• 公网业务、数据库和管理服务分层，数据库不直接暴露在公网。
• 所有网络、虚拟机XML和存储调整都有备份，远程操作可通过控制台回退。

如果服务器实际内存为256GB，可以采用以下初始资源池：

如果是128GB内存，可以先按“宿主机20GB、虚拟机96GB、缓冲12GB”规划；512GB内存则可以按“宿主机48GB、虚拟机400GB、缓冲64GB”作为起点。最终数值仍需结合实际磁盘缓存、监控组件和业务进程占用进行调整。

A5数据提供香港AMD EPYC物理服务器，涵盖EPYC 7713等多核心平台，并有不同内存、SSD或NVMe存储及CN2、国际带宽配置，为KVM多虚拟机部署提供计算、存储与网络资源基础。这类资源组合可承载Web入口、API、数据库和后台任务等不同角色，支持企业将多项业务集中部署，并按角色划分虚拟机的CPU、内存与磁盘资源。

2. 核对CPU、内存、磁盘和NUMA

在正式安装KVM前，先确认硬件信息和虚拟化扩展。以下命令只读，不会改变配置：

lscpu
lscpu -e=CPU,CORE,SOCKET,NODE,ONLINE
free -h
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
df -hT
numactl -H 2>/dev/null || true
grep -Eo 'svm' /proc/cpuinfo | sort | uniq -c

重点观察以下内容：

• CPU(s)是否为128。
• Core(s) per socket与Socket(s)是否符合实际部署方式。
• 是否存在多个NUMA节点。
• MemAvailable是否明显低于物理内存，避免系统已经被其他服务占用。
• /var/lib/libvirt所在磁盘是否有足够空间。
• 存储是否为本地SSD、NVMe、硬件RAID或网络存储。
• svm是否存在。AMD平台需要在BIOS中启用SVM虚拟化扩展。

如果宿主机本身运行着面板、备份、监控或其他生产服务，必须把它们的资源占用计入预留值。不能只按服务器标称内存和核心数计算虚拟机总量。

3. 核对25M CN2线路的计量方式

“25M CN2”至少要向服务商确认以下项目：

• 25M是25Mbps还是25MB/s。
• 是独享带宽还是共享端口。
• 计费和限速针对上行、下行，还是双向合计。
• 是否允许多个虚拟机使用独立公网IP和独立MAC地址。
• 是否有突发带宽，突发后是否回落到25Mbps。
• 是否存在流量包、峰值计费或特定方向的限制。

如果25M按25Mbps计算，十进制换算如下：

• 25Mbps ÷ 8 = 3.125MB/s理论传输速率。
• 按24小时持续占满计算：3.125MB/s × 86,400秒 = 270,000MB，约270GB/天。
• 按30天持续占满计算：270GB × 30 = 8,100GB，约8.1TB。

这个数值是单方向、理论满速且不扣除协议开销的估算，不能直接等同于业务可用流量。如果线路对上下行合计限速，也不能把上行和下行分别都按25Mbps计算。

4. 备份当前配置

涉及远程网络、虚拟机XML和磁盘配置的操作都应先备份。备份目录应放在独立磁盘或远程存储中，不能只留在即将修改的系统盘上。

sudo install -d -m 700 /root/kvm-change-backup
sudo cp -a /etc/netplan /root/kvm-change-backup/netplan-$(date +%F-%H%M%S)
sudo virsh -c qemu:///system list --all
sudo virsh -c qemu:///system dumpxml --inactive vm-web01 \
  > /root/kvm-change-backup/vm-web01.xml 2>/dev/null || true
sudo lsblk -f > /root/kvm-change-backup/lsblk.txt
sudo ip -br addr > /root/kvm-change-backup/ip-addr.txt
sudo ip route > /root/kvm-change-backup/ip-route.txt

vm-web01只是示例名称。如果虚拟机尚未创建，导出XML的命令会失败，不影响其他备份。

数据库虚拟机还应使用数据库自身的逻辑备份或物理备份。单纯复制正在写入的qcow2文件，不能替代一致性备份。

分步操作

1. 安装并验证KVM环境

以下命令适用于Ubuntu Server。安装前应确认系统版本和软件源正常：

cat /etc/os-release
uname -r
sudo apt update
sudo apt install -y \
  qemu-kvm \
  libvirt-daemon-system \
  libvirt-clients \
  virtinst \
  qemu-utils \
  bridge-utils \
  cpu-checker \
  libguestfs-tools

启动libvirt并检查宿主机能力：

sudo systemctl enable --now libvirtd
sudo virsh -c qemu:///system list --all
sudo virt-host-validate qemu
sudo kvm-ok 2>/dev/null || true
ls -l /dev/kvm

Ubuntu不同版本可能同时使用libvirtd、virtqemud等拆分服务。如果libvirtd不存在，应先核对实际服务名称：

systemctl list-unit-files | grep -E 'libvirt|virtqemu'
systemctl status libvirtd virtqemud --no-pager 2>/dev/null || true

正常情况下，/dev/kvm存在，virt-host-validate qemu不应出现阻断虚拟化启动的错误。如果宿主机是上一层虚拟机，还需要服务商开放嵌套虚拟化；普通系统内命令无法补足未开放的SVM能力。

2. 配置宿主机桥接网络

虚拟机需要直接使用公网IP时，通常采用Linux Bridge。桥接之前必须确认服务商允许额外MAC地址、额外公网IP或对应的路由方式。只有一个公网IP时，不应把同一个IP直接配置到多台虚拟机上。

先查看真实网卡名称和当前路由：

ip -br link
ip -br addr
ip route

假设宿主机物理网卡为ens3，以下是静态公网地址的Netplan结构示例。尖括号内容必须替换成服务商提供的实际参数：

# /etc/netplan/01-br0.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: false
      dhcp6: false
  bridges:
    br0:
      interfaces:
        - ens3
      addresses:
        - /
      routes:
        - to: default
          via: 
      nameservers:
        addresses:
          - 
          - 
      parameters:
        stp: false
        forward-delay: 0

不要直接覆盖现有Netplan文件。远程修改网卡配置前应准备服务商控制台、带外管理或现场回退通道。确认语法后，优先使用带自动回滚能力的测试模式：

sudo netplan generate
sudo netplan try --timeout 120

如果控制台和SSH均正常，再执行：

sudo netplan apply
ip -br addr show br0
ip route
bridge link

netplan try期间如果失去连接，等待测试超时通常会回滚。如果已经执行了错误配置，应通过控制台恢复备份文件，而不是在SSH断开的情况下反复修改。

如果公网采用DHCP、服务商使用静态路由，或要求网关与地址不在同一子网，Netplan结构会不同。此时应以服务商交付的网络参数为准，不要套用上面的静态示例。

3. 规划公网网络与内部网络

建议至少划分以下网络角色：

数据库虚拟机最好只有内部业务网卡，备份与管理通过受控网络访问。如果业务确实需要独立公网IP，应在防火墙、监听地址和访问控制层面限制端口，而不是仅依赖虚拟机内部系统。

如果服务商只分配一个公网IP，可以让宿主机承载公网入口，再把业务虚拟机放在内部网络中，通过正常的端口映射或企业Web反向代理发布指定服务。数据库端口不应直接映射到公网。

4. 检查libvirt存储池与磁盘余量

先查看libvirt已有存储池：

sudo virsh -c qemu:///system pool-list --all
sudo virsh -c qemu:///system pool-info default 2>/dev/null || true
sudo lvs -a -o vg_name,lv_name,lv_size,lv_attr,data_percent,metadata_percent
df -hT /var/lib/libvirt

生产环境可按业务特征选择存储方式：

• 普通Web和应用虚拟机：qcow2便于复制、扩容和迁移。
• 数据库或高I/O任务：优先考虑原始逻辑卷、预分配磁盘或性能稳定的NVMe存储。
• 使用LVM thin pool时：必须监控data_percent和metadata_percent，不要把逻辑容量全部分配出去。
• 虚拟机快照只能作为短期变更保护，不能代替异地备份。

建议将thin pool的数据使用率控制在75%以内，达到85%时停止继续创建磁盘并处理扩容或清理。元数据空间不足会导致虚拟磁盘写入异常，影响范围可能扩大到同一thin pool中的多台虚拟机。

5. 按业务角色创建虚拟机

以256GB内存为例，第一批虚拟机可以按以下方式分配：

表中固定虚拟机合计50个vCPU、164GB内存，仍低于本方案建议的56个vCPU和192GB虚拟机资源池。数据库的带宽只按业务复制、管理和备份估算，不代表允许数据库直接接受公网连接。

创建磁盘时，确认目标文件不存在，避免误操作覆盖已有数据：

sudo test ! -e /var/lib/libvirt/images/vm-web01.qcow2
sudo qemu-img create \
  -f qcow2 \
  -o preallocation=metadata \
  /var/lib/libvirt/images/vm-web01.qcow2 \
  100G
sudo qemu-img info /var/lib/libvirt/images/vm-web01.qcow2

生产磁盘路径、存储池和容量需要按实际环境替换。qemu-img create只能用于新文件；对已有虚拟磁盘执行转换、压缩或格式变更前，必须先做完整备份，并在备用文件上验证。

创建示例虚拟机：

sudo virt-install \
  --connect qemu:///system \
  --name vm-web01 \
  --memory 16384 \
  --vcpus 8,maxvcpus=8 \
  --cpu host-passthrough \
  --disk path=/var/lib/libvirt/images/vm-web01.qcow2,format=qcow2,bus=virtio,cache=none,discard=unmap \
  --network bridge=br0,model=virtio \
  --os-variant ubuntu22.04 \
  --cdrom /var/lib/libvirt/boot/ubuntu-22.04.iso \
  --graphics none \
  --console pty,target_type=serial

host-passthrough可以提供较接近宿主机的CPU特性，但会降低跨不同CPU主机迁移的兼容性。如果后续有异构迁移需求，可考虑host-model，但应在目标主机上先验证指令集兼容性。

6. 配置CPU、内存与NUMA

第一阶段不要把128个逻辑线程全部分配给虚拟机。建议使用以下规则：

• CPU持续计算型业务：虚拟机总vCPU先控制在宿主机物理核心预算以内，示例为50至56个vCPU。
• Web、API、监控等混合负载：可在监控稳定后逐步提升到64至96个vCPU，但不能以此作为CPU密集型业务的承诺。
• 宿主机至少保留约8个物理核心等效资源，不能只保留1至2个逻辑线程。
• 8vCPU及以下的普通虚拟机可先不固定CPU亲和性。
• 对数据库、编译、低延迟任务，再根据NUMA和监控结果进行绑定。

先查看物理核心、逻辑线程和NUMA节点对应关系：

lscpu -e=CPU,CORE,SOCKET,NODE,ONLINE
numactl -H
sudo virsh -c qemu:///system capabilities | grep -E 'host|topology|numa' -A8

如果需要固定CPU，应先备份虚拟机XML：

sudo virsh -c qemu:///system dumpxml --inactive vm-web01 \
  > /root/kvm-change-backup/vm-web01-before-pinning.xml

再根据lscpu -e输出选择完整物理核心。以下命令仅表示格式，16必须替换为实际宿主机CPU编号：

sudo virsh -c qemu:///system vcpupin vm-web01 0 16 --config
sudo virsh -c qemu:///system vcpupin vm-web01 1 18 --config
sudo virsh -c qemu:///system vcpupin vm-web01 2 20 --config
sudo virsh -c qemu:///system vcpupin vm-web01 3 22 --config
sudo virsh -c qemu:///system vcpupin vm-web01 4 17 --config
sudo virsh -c qemu:///system vcpupin vm-web01 5 19 --config
sudo virsh -c qemu:///system vcpupin vm-web01 6 21 --config
sudo virsh -c qemu:///system vcpupin vm-web01 7 23 --config

不要把同一物理核心的两个SMT线程分别分配给两个高负载虚拟机。对延迟敏感的虚拟机，可以将同一物理核心的两个线程交给同一虚拟机，或让其中一个线程空闲，具体取决于负载类型。

NUMA绑定必须以numactl -H的实际结果为准。若虚拟机的内存超过单个NUMA节点可用容量，强行设置strict可能导致虚拟机无法启动。调整NUMA前应安排维护窗口，并准备XML回滚文件。

数据库和缓存服务建议采用固定内存。普通应用可以使用内存气球，但必须安装并验证客户机驱动，且不能把气球机制当作宿主机内存不足时的唯一保护手段。宿主机进入OOM状态时，优先停止低优先级CI或计算虚拟机，不要直接强制关闭数据库虚拟机。

7. 配置25Mbps线路的虚拟机带宽

25Mbps线路不应按虚拟机数量平均切分。应先根据业务角色设定平均速率，再为突发保留空间。示例中各虚拟机平均速率合计约16Mbps，峰值合计控制在约23Mbps，给宿主机管理和协议开销留下余量。

libvirt可以在虚拟机网卡XML中设置每台虚拟机的带宽。修改前先备份XML，并安排虚拟机重启窗口：

sudo virsh -c qemu:///system dumpxml --inactive vm-web01 \
  > /root/kvm-change-backup/vm-web01-before-bandwidth.xml

以下是网卡配置片段，单位为kbps。它表示平均6Mbps、峰值8Mbps；如果服务商只限制一个方向，应结合计量方向调整对应项目：

可以使用virsh edit修改持久配置，但不要在没有XML备份的情况下直接操作：

sudo virsh -c qemu:///system edit vm-web01

如果要求宿主机外联口硬性不超过25Mbps，还需要在真实外联网卡上配置流量整形。下面命令只示范出口方向，并且会替换该网卡现有的根队列；执行前必须保存当前队列配置，确认没有其他QoS策略：

sudo tc qdisc show dev ens3 | tee /root/kvm-change-backup/tc-ens3-before.txt
sudo tc qdisc replace dev ens3 root handle 1: \
  tbf rate 25mbit burst 64kb latency 50ms
sudo tc -s qdisc show dev ens3

这项设置会影响宿主机和通过该物理网卡发送的虚拟机流量，且主要限制出口方向。不要在不了解服务商计量方式时直接套用。如果已有云厂商QoS、硬件队列或复杂整形规则，应该由网络管理员在现有策略上增加分类，而不是直接替换根队列。

8. 启动并逐台扩容

完成单台虚拟机安装后，不要一次性启动全部实例。建议按“管理虚拟机、Web入口、应用、数据库、任务虚拟机”的顺序逐台启动，每启动一台就检查CPU、内存、磁盘和网络。

sudo virsh -c qemu:///system start vm-web01
sudo virsh -c qemu:///system dominfo vm-web01
sudo virsh -c qemu:///system domiflist vm-web01
sudo virsh -c qemu:///system domblklist vm-web01

首次上线时，建议先维持表格中的固定资源运行24小时以上，观察业务峰值和资源争用，再决定是否增加vCPU或内存。直接把虚拟机从8vCPU扩展到32vCPU，不一定能提高性能，反而可能增加调度、锁竞争和NUMA访问成本。

结果验证

1. 验证虚拟机看到的资源

进入客户机后检查CPU拓扑、内存和网卡：

lscpu
free -h
ip -br addr
ip route
ip -br link

宿主机侧检查虚拟机实际配置：

sudo virsh -c qemu:///system dominfo vm-web01
sudo virsh -c qemu:///system vcpupin vm-web01
sudo virsh -c qemu:///system dommemstat vm-web01
sudo virsh -c qemu:///system domifstat vm-web01
sudo virsh -c qemu:///system domblklist vm-web01

如果客户机显示的vCPU数量、内存与配置不一致，先检查虚拟机是否使用旧配置启动，或是否存在maxmemory、热插拔和气球配置差异。

2. 验证CPU争用

宿主机执行：

mpstat -P ALL 1 5
vmstat 1 5
top

客户机执行：

vmstat 1 5
top

重点观察：

• 宿主机是否长期接近满载。
• 客户机steal是否持续升高。
• 客户机是否有明显的iowait。
• vCPU绑定后，是否出现某几个逻辑CPU长期100%而其他CPU空闲。
• QEMU模拟线程是否与数据库或计算任务争用同一核心。

作为初始验收参考，普通业务在稳定时客户机steal可控制在2%以内；持续超过5%时，应检查vCPU超售、CPU绑定、宿主机后台任务和NUMA布局。这个阈值是运维参考，不是所有业务的统一SLA。

3. 验证内存和磁盘

宿主机：

free -h
cat /proc/meminfo | egrep 'MemAvailable|SwapFree|SwapTotal|Unevictable'
sudo lvs -a -o vg_name,lv_name,lv_size,lv_attr,data_percent,metadata_percent

客户机：

free -h
swapon --show
df -hT

数据库虚拟机不建议依赖宿主机交换分区来缓解内存不足。发现内存不足时，应先降低低优先级虚拟机的内存、停止不必要任务或扩容宿主机，而不是立即让数据库进入高频交换。

磁盘I/O检查：

iostat -xz 1 5
sudo virsh -c qemu:///system domblkstat vm-web01

如果磁盘延迟升高而CPU和带宽都正常，应检查底层SSD、RAID缓存、thin pool使用率、qcow2增长方式和备份任务。不要把所有磁盘问题归因于vCPU不足。

4. 验证25Mbps线路

查看网卡和虚拟网卡统计：

ip -s link show ens3
sudo tc -s qdisc show dev ens3
sudo virsh -c qemu:///system domifstat vm-web01
sar -n DEV 1 5

如需测试线路，应使用已授权的测试端点，并采用逐步加压方式。建议先以20至22Mbps左右的目标流量验证稳定性，再观察：

• 是否出现丢包、重传和网卡错误。
• 多台虚拟机同时发送时，是否有某一台长期占满线路。
• tc是否出现drop或overlimits持续增长。
• 服务商端显示的速率是否与宿主机统计口径一致。
• 上行、下行或双向计量是否符合交付约定。

不要用单次测速结果替代长期带宽监控。25Mbps线路适合中小规模Web、API和管理业务，但不适合在没有限速策略的情况下承载多台虚拟机的持续镜像分发、大量视频文件输出或全量备份。

5. 验证重启、备份与恢复

至少完成一次以下测试：

1. 正常关闭并启动一台非核心测试虚拟机。
2. 重启宿主机，确认libvirt和虚拟机自启动策略符合预期。
3. 从备份恢复一台测试虚拟机到不同名称和磁盘路径。
4. 关闭一条非必要网络配置后，确认可以通过控制台恢复。
5. 检查数据库备份是否能够在独立目录或独立主机上读取。

只确认“备份文件存在”不算恢复验证。恢复测试应包括虚拟机能够启动、业务进程能够运行、磁盘数据可读和网络配置不冲突。

失败处理

KVM无法启动或没有/dev/kvm

执行以下检查：

sudo virt-host-validate qemu
ls -l /dev/kvm
grep -Eo 'svm' /proc/cpuinfo | sort | uniq -c
dmesg | grep -iE 'kvm|svm|virtual'

常见原因包括：

• BIOS未启用SVM。
• 当前服务器实际上是未开放嵌套虚拟化的上一层虚拟机。
• 内核模块未加载。
• libvirt服务异常。
• 宿主机CPU特性被服务商屏蔽。

如果是BIOS或云平台能力问题，不要通过修改虚拟机参数绕过，应联系机房或服务商确认。

桥接后宿主机断网

这类操作的影响范围是宿主机、所有桥接虚拟机和远程管理连接。处理顺序如下：

1. 立即使用控制台或带外管理登录。
2. 查看/etc/netplan中是否存在重复配置。
3. 恢复变更前的Netplan备份。
4. 执行netplan generate检查语法。
5. 使用netplan apply恢复网络。
6. 确认宿主机路由和SSH恢复后，再处理虚拟机网卡。

不要在SSH已断开的情况下继续尝试多个网络配置。若服务商要求绑定特定MAC、静态路由或网关参数，桥接文件必须按交付方式调整。

虚拟机无法启动

先查看状态和日志：

sudo virsh -c qemu:///system dominfo vm-web01
sudo journalctl -u libvirtd -u virtqemud --since "-15 min" --no-pager
sudo virsh -c qemu:///system dumpxml vm-web01
sudo qemu-img check /var/lib/libvirt/images/vm-web01.qcow2

常见原因包括：

• 磁盘路径不存在或权限错误。
• qcow2文件损坏。
• NUMA绑定的节点没有足够内存。
• host-passthrough与当前CPU环境不兼容。
• 网桥名称错误。
• XML修改造成设备重复或格式错误。

不要直接删除磁盘或执行格式化操作。先复制磁盘文件或从备份恢复到新路径，再在副本上执行检查。

性能低于预期

按以下顺序排查：

1. 查看客户机steal，确认是否CPU争用。
2. 查看宿主机内存是否接近耗尽。
3. 检查数据库是否发生交换。
4. 查看iostat确认磁盘延迟。
5. 检查虚拟网卡和物理网卡是否丢包。
6. 查看25Mbps线路是否被其他虚拟机占用。
7. 检查vCPU是否跨NUMA节点或错误绑定。
8. 暂停低优先级CI、编译和批处理任务，再观察业务延迟。

增加vCPU应当以监控结果为依据。如果应用本身是单线程瓶颈，增加到更多vCPU并不会自动提高吞吐；如果数据库受磁盘延迟限制，优先更换存储策略也比单纯扩展CPU有效。

内存不足或宿主机触发OOM

先确认内存状态：

free -h
dmesg -T | grep -iE 'oom|out of memory|killed process'
sudo virsh -c qemu:///system list

处理顺序建议为：

1. 停止低优先级计算或CI虚拟机中的任务。
2. 正常关闭不重要的测试虚拟机。
3. 减少非核心虚拟机的固定内存。
4. 核对数据库备份和业务一致性。
5. 必要时扩容宿主机或迁移部分虚拟机。

virsh destroy相当于强制断电，可能造成客户机文件系统和数据库损坏。只有在virsh shutdown无响应且已确认业务允许中断时，才使用：

sudo virsh -c qemu:///system shutdown vm-ci01

等待无响应并确认影响后，才考虑强制停止：

sudo virsh -c qemu:///system destroy vm-ci01

带宽被单台虚拟机占满

先用domifstat、tc -s和业务日志确认流量来源。若是备份、镜像分发或文件下载造成，可以降低该虚拟机的平均速率和峰值，或安排到业务低峰执行。

调整限速前应保存当前XML。限速配置只影响对应虚拟网卡，但宿主机根队列整形会影响所有虚拟机，处理时必须区分两种范围。

回滚方案

回滚虚拟机XML

如果CPU绑定、NUMA或带宽设置导致虚拟机无法启动，先停止继续修改，使用变更前XML恢复持久配置：

sudo virsh -c qemu:///system shutdown vm-web01
sudo virsh -c qemu:///system define \
  /root/kvm-change-backup/vm-web01-before-pinning.xml
sudo virsh -c qemu:///system start vm-web01

如果客户机长时间不响应，shutdown无法完成时，强制停止会造成未写入数据丢失。执行前应确认已经有业务备份，并记录影响范围。

回滚网络配置

通过控制台恢复Netplan文件：

sudo cp -a /root/kvm-change-backup/netplan-/01-br0.yaml \
  /etc/netplan/01-br0.yaml
sudo netplan generate
sudo netplan apply
ip -br addr
ip route

替换为备份目录中的实际时间戳。不要在没有确认文件内容的情况下执行覆盖。若原系统存在多个Netplan文件，还要检查是否有重复的网卡、路由或DNS定义。

回滚宿主机出口整形

如果确认新配置造成出口异常，并且此前没有其他根队列策略，可以删除示例中的根队列：

sudo tc qdisc del dev ens3 root
sudo tc -s qdisc show dev ens3

这会恢复系统默认队列，但如果变更前存在服务商或本地自定义QoS，也可能一并删除。因此正式环境必须以变更前保存的tc-ens3-before.txt为依据恢复，不要盲目执行删除。

回滚磁盘和快照

正在运行的数据库不应直接回滚到旧快照。快照回滚会丢失快照之后的写入，影响范围可能包括数据库、日志、上传文件和配置变更。

更安全的方式是：

1. 关闭或冻结业务写入。
2. 使用数据库备份恢复到新虚拟磁盘。
3. 将新磁盘挂载到恢复虚拟机。
4. 验证数据和应用后，再切换业务入口。
5. 保留原磁盘，确认恢复完成后再清理。

清理qcow2快照、删除thin pool卷或删除虚拟机磁盘前，必须确认备份可读并明确影响对象。删除命令不可作为常规故障排查手段。

上线验收清单

上线前逐项确认以下内容：

• [ ] 宿主机已确认EPYC 7713核心、线程、内存和NUMA拓扑。
• [ ] BIOS或平台已启用AMD SVM，/dev/kvm正常。
• [ ] 宿主机预留了足够的内存和物理核心，没有把128个逻辑线程全部分配出去。
• [ ] 虚拟机vCPU、内存和磁盘容量与业务角色匹配。
• [ ] 数据库使用固定内存，未直接暴露不必要的公网端口。
• [ ] 公网IP、MAC、网桥和服务商路由方式已完成核对。
• [ ] Netplan、虚拟机XML和存储信息均有独立备份。
• [ ] 25M线路的单位、方向、共享方式和计量规则已确认。
• [ ] 虚拟机平均带宽之和低于线路上限，并保留管理与故障缓冲。
• [ ] 宿主机和虚拟机均无持续高steal、高交换、高I/O等待或网卡丢包。
• [ ] thin pool或磁盘池使用率已设置监控和告警。
• [ ] 完成至少一次虚拟机重启、备份读取和恢复验证。
• [ ] 已记录网络回滚、XML回滚和低优先级虚拟机停止顺序。
• [ ] 扩容策略明确：先观察监控，再增加vCPU、内存或带宽，不一次性填满资源池。

以这套方式部署时，64核128线程EPYC 7713的重点不是追求虚拟机数量，而是保留宿主机调度余量、让数据库和应用获得稳定资源，并将25Mbps香港线路纳入统一的带宽预算。初始配置保持适度保守，经过CPU、内存、磁盘和网络监控验证后再扩容，更适合长期运行和后续故障处理。