PVE on 南洋楹树洞

Fan Control on PVE

Thu, 23 Jul 2026 00:00:00 +0800

Fan Control on PVE

Tested on: ASUS TUF GAMING B550M-PLUS / AMD Ryzen 5 5600 / Nuvoton NCT6798D

1. Load the Driver

apt update && apt install lm-sensors
sensors-detect             # Accept defaults, say yes to write to /etc/modules
modprobe nct6775
sensors                    # Verify fan RPM and temperature readings appear

2. Identify the Active PWM Channel

pwmconfig automatically maps each PWM control to the fan it actually drives, saving guesswork.

apt install fancontrol     # pwmconfig ships with fancontrol
pwmconfig

Answer y to switch each PWM channel to manual mode. The tool will briefly stop each fan and measure RPM changes. Sample output:

Testing pwm control hwmon3/pwm2 ...
  hwmon3/fan2_input ... speed was 2872 now 675
    It appears that fan hwmon3/fan2_input is controlled by pwm hwmon3/pwm2

    PWM 255 FAN 2842    PWM 120 FAN 1726
    PWM 240 FAN 2760    PWM 105 FAN 1553
    PWM 225 FAN 2626    PWM 90  FAN 1351
    PWM 210 FAN 2532    PWM 75  FAN 1166
    PWM 195 FAN 2385    PWM 60  FAN 942
    PWM 180 FAN 2295    PWM 45  FAN 789
    PWM 165 FAN 2136    PWM 30  FAN 566
    PWM 150 FAN 2002    PWM 0-28 FAN ~490
    PWM 135 FAN 1849

Exit with Ctrl+C or answer n to skip remaining channels once you’ve found the one controlling your target fan.

3. Create the Fixed-Speed Script

The script resolves the hwmon device by name at runtime, so it survives reboots and kernel updates without changes.

cat > /root/pve-fan-fixed.sh << 'EOF'
#!/bin/bash
HWMON=$(grep -l nct6798 /sys/class/hwmon/hwmon*/name | grep -oP 'hwmon\d+')
[ -z "$HWMON" ] && exit 1
echo 1 > /sys/class/hwmon/"$HWMON"/pwm2_enable
echo 225 > /sys/class/hwmon/"$HWMON"/pwm2
EOF
chmod +x /root/pve-fan-fixed.sh

pwmN_enable values: 1 = Manual, 2 = Thermal, 5 = BIOS/ACPI (default)

4. Set Up the systemd Service

cat > /etc/systemd/system/pve-fan-fixed.service << 'EOF'
[Unit]
Description=Set fixed fan speed
After=systemd-modules-load.service

[Service]
Type=oneshot
ExecStart=/root/pve-fan-fixed.sh

[Install]
WantedBy=multi-user.target
EOF
systemctl enable --now pve-fan-fixed.service

5. Adjusting the Speed

sed -i '/pwm2_enable/! s/echo [0-9]*/echo 225/' /root/pve-fan-fixed.sh
systemctl restart pve-fan-fixed.service

Or just nano /root/pve-fan-fixed.sh and change the number on the last line.

PWM to RPM Mapping

Data measured from your actual hardware via pwmconfig. Noise description is approximate.

PWM	RPM	Noise
255	2842	Full speed
225	2626	High ← Current
180	2295	Medium-high
150	2002	Medium
120	1726	Medium-low
105	1553	Quiet
80	~1300	Quiet
60	942	Very quiet
30	566	Extremely quiet
0-28	~490	Minimum

Uninstall

systemctl disable --now pve-fan-fixed.service
rm /etc/systemd/system/pve-fan-fixed.service /root/pve-fan-fixed.sh

PVE 磁盘健康检测

Wed, 03 Jun 2026 00:00:00 +0800

PVE 磁盘健康检测

一、快速查看磁盘状态

1. SMART 检测

smartctl -A /dev/sdX     # 查看属性摘要
smartctl -H /dev/sdX     # 查看健康状态（PASSED/FAILED）

也可通过 PVE Web UI 查看：选中节点 → 磁盘 → 选择磁盘 → SMART 状态。若显示"未知"，先在命令行启用：

smartctl -s on /dev/sdX

实际输出：`smartctl -A /dev/sda`

smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.12-25-pve] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   195   051    Pre-fail  Always       -       1
  3 Spin_Up_Time            0x0027   220   216   021    Pre-fail  Always       -       1983
  4 Start_Stop_Count        0x0032   098   098   000    Old_age   Always       -       2523
  5 Reallocated_Sector_Ct   0x0033   193   193   140    Pre-fail  Always       -       31424
  7 Seek_Error_Rate         0x002e   200   198   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   043   043   000    Old_age   Always       -       42059
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       1594
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       365
193 Load_Cycle_Count        0x0032   010   010   000    Old_age   Always       -       572990
194 Temperature_Celsius     0x0022   096   092   000    Old_age   Always       -       51
196 Reallocated_Event_Count 0x0032   001   001   000    Old_age   Always       -       384
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       77

二、SMART 数据解读

判断标准：VALUE 范围 1~253（越大越好），低于 THRESH 标记 FAILING_NOW。RAW_VALUE 为原始计数值。

以下是关键属性说明，以及上面 smartctl -A /dev/sda 输出中对应的实际数据和风险评估：

ID	属性名	含义	实际值	警戒值	风险评估
5	Reallocated_Sector_Ct	已重映射扇区数	31424	> 0 需警惕，> 100 建议换盘	🚨 极高：备用区大量消耗
196	Reallocated_Event_Count	重映射事件次数	384	持续增长说明盘面加速劣化	⚠️ 384 次，持续分批出现
197	Current_Pending_Sector	待稳定扇区	0	> 0 说明存在不稳定扇区	✅ 正常
198	Offline_Uncorrectable	无法纠正的扇区	0	> 0 说明存在物理坏道	✅ 正常
1	Raw_Read_Error_Rate	原始读取错误率	1	VALUE 持续下降说明磁头/盘面有问题	✅ 正常
7	Seek_Error_Rate	寻道错误率	0	VALUE 大幅下降说明机械臂异常	✅ 正常
9	Power_On_Hours	通电时间	42059	机械盘一般寿命 3~5 万小时	~4.8 年
193	Load_Cycle_Count	磁头加载/卸载次数	572990	WD 盘额定约 30~60 万次	🚨 接近寿命极限
194	Temperature_Celsius	温度	51°C	建议 < 45°C，> 55°C 加速老化	⚠️ 偏高

磁盘经历过大量坏道（3 万+），目前虽已被固件重映射、读写正常，但备用区消耗殆尽、负载周期接近寿命极限，健康状况堪忧。

快查指令

smartctl -A /dev/sdX | grep -E "^(  5|197|198)"

# 5=0, 197=0, 198=0 → 良好
# 5>0, 197=0, 198=0 → 旧坏道已被重映射，看数量判断风险
#   个位数：可监控使用，两位数及以上：建议换盘，持续增长中：立即换盘
# 197>0 或 198>0  → 当前存在坏道，需处理

三、深入扫描检测

SMART 只是磁盘固件记录的日志，如果需要确认实际扇区状况，做深度的全盘扫描。

1. SMART 长测试

smartctl -t long /dev/sdX        # 提交测试，由磁盘固件后台执行，立即返回

查看测试结果：

smartctl -l selftest /dev/sdX    # 查看自检记录
smartctl -l error /dev/sdX       # 查看 I/O 错误日志

实际输出

# 提交长测试（耗时约 6 小时，后台执行，立即返回）
smartctl -t long /dev/sda

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 371 minutes for test to complete.
Test will complete after Wed Jun  3 19:12:06 2026 CST
Use smartctl -X to abort test.

# 查看自检记录
smartctl -l selftest /dev/sda

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       90%     42079         1427497600
# 2  Extended offline    Completed: read failure       90%     42066         1427497600

# 查看 I/O 错误日志
smartctl -l error /dev/sda

=== START OF READ SMART DATA SECTION ===
SMART Error Log Version: 1
No Errors Logged

结果解读

#2（LifeTime 42066h） — 第一次测试，等了约 6 小时后查到的结果，Remaining 90% 说明测试仅执行了约 10% 就遇到读取错误并终止
#1（LifeTime 42079h） — 第二次提交后立即就查询到结果，因为同一 LBA 仍在报错，固件在相同位置再次中止测试
同一 LBA（1427497600）两次测试均报错 — 确认该扇区存在可复现的物理缺陷，非偶发性
No Errors Logged — 自检发现的错误记录在 selftest 日志中，与 -l error（记录主机 I/O 层面的读写错误）是两套独立的日志；自检报错不代表一定有主机 I/O 错误

后续操作

# 确认重映射扇区数是否增加
smartctl -A /dev/sda | grep -E "^(  5|196|197|198)"

  5 Reallocated_Sector_Ct   0x0033   193   193   140    Pre-fail  Always       -       31424
196 Reallocated_Event_Count 0x0032   001   001   000    Old_age   Always       -       384
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0

重映射数未增加，所有属性值与初始检测时一致。说明：

固件已知该 LBA 有问题（长测试两次确认），但未分配备用扇区进行重映射
最可能的原因：备用区已耗尽（31424 个），无可用扇区
Current_Pending_Sector 仍为 0 是因为长测试报的是读取失败，而非等待重映射的待稳定状态，两者机制不同

2. badblocks 全盘扫描

逐扇区读写校验，是检测坏道最严格的手段（1TB 盘约 4~8 小时），耗时较长用 nohup 后台执行：

# 只读扫描（不破坏数据）
nohup badblocks -sv /dev/sdX > /root/badblocks-scan.log 2>&1 &

# 非破坏性读写扫描（写入→校验→恢复，更严格）
nohup badblocks -svn /dev/sdX > /root/badblocks-scan.log 2>&1 &

# 查看进度
tail -f /root/badblocks-scan.log

扫描结果

Checking for bad blocks in non-destructive read-write mode
From block 0 to 1953514583
Testing with random pattern: done
Pass completed, 0 bad blocks found. (0/0/0 errors)

全盘约 1TB 范围全部通过，零个坏块。

3. smartctl 与 badblocks 的区别

两个工具检测的维度和方式完全不同：

	smartctl	badblocks
检测对象	磁盘固件记录的 SMART 日志和属性	实际的磁盘扇区
检测方式	读取磁盘内置的 SMART 数据（由磁盘固件持续记录）	逐扇区读写校验
能否发现已重映射的坏道	✅ 能，从 `Reallocated_Sector_Ct` 看出历史累计量	❌ 不能，坏道已被映射到备用区，读的是好数据
能否发现不稳定扇区	✅ `Current_Pending_Sector` > 0	✅ 读写不稳定会报错
执行速度	毫秒级（读固件数据）	数小时到数天（逐扇区扫描）
影响数据	只读，无影响	`-n` 模式无影响，`-w` 模式会破坏数据
主要用途	快速初筛、历史追踪、趋势分析	深度扫描、确认坏道位置、触发重映射

使用建议：

先用 smartctl -A 快速查看属性，几分钟就能做完初步判断
如果 SMART 数据正常，一般不需要跑 badblocks
如果 SMART 数据异常（Reallocated_Sector_Ct 高、Current_Pending_Sector > 0），再针对性地跑 badblocks 做深度扫描

FAQ

为什么 SMART 差但 badblocks 无坏道？

磁盘固件已将坏道重映射到备用区，badblocks 读的是备用扇区的好数据，因此不报错。

逻辑层（badblocks 看到的）:
  LBA 0  → 正常读取
  LBA 1  → 正常读取
  LBA 2  → 被重映射 → 实际读取的是备用扇区 → 数据正常
  LBA 3  → 正常读取
  结论：所有 LBA 都能正常读写 → 0 bad blocks

物理层（盘面实际情况）:
  LBA 2 对应的物理位置已损坏（坏道）
     ↓
  固件自动将 LBA 2 映射到盘片深处的备用区（G-List）
     ↓
  上层（包括 badblocks）读 LBA 2 → 去备用区读 → 一切正常

badblocks 工作在逻辑层，读的是 LBA。坏道已被重映射到备用区，它读到的是好数据，自然报 0
Reallocated_Sector_Ct 不可逆地记录磁盘一生中遇到过的所有物理缺陷
badblocks 通过不代表磁盘健康，必须结合 SMART 综合判断

badblocks 报出坏道的场景

情况	badblocks 结果
磁盘健康	0 bad blocks ✅
坏道已被固件重映射	0 bad blocks ⚠️（假阴性）
有不稳定扇区但未重映射	报出坏道
备用区已耗尽，新坏道无法重映射	报出坏道 🚨

综合判断

结合上面的数据综合评估：

指标	数据	结论
`Reallocated_Sector_Ct`	31424	🚨 备用区大量消耗
`Reallocated_Event_Count`	384 次	⚠️ 持续分批出现，盘面加速劣化
`Load_Cycle_Count`	572990	🚨 接近设计寿命上限
`Temperature`	51°C	⚠️ 偏高，加速老化
`Current_Pending_Sector`	0	✅ 当前无活跃坏道
`badblocks`	0 bad blocks	✅ 当前读写正常
`Power_On_Hours`	42059	约 4.8 年
SMART 长测试	两次 `read failure` 于同一 LBA（1427497600）	🚨 存在可复现的物理缺陷，且重映射数未增加
`Reallocated_Sector_Ct`（复查）	仍为 31424	🚨 备用区已耗尽，固件无法分配新扇区

结论：磁盘健康状况堪忧，建议尽快替换。 原因不是"当前有坏道"（已被固件挡住），而是备用区已消耗殆尽，一旦下一个坏道出现就可能导致数据丢失。

LVM 迁移至 LVM-Thin

Thu, 28 May 2026 00:00:00 +0800

LVM 迁移至 LVM-Thin

场景说明

双节点集群，节点名分别为 pve 和 x370：

节点	系统盘	外挂存储	初始状态
pve	1T NVMe	2T HDD（挂载为 `hdd`）	有 LVM，无 Thin Pool，运行 VM-104（384G，实际 ~150G）、VM-110（384G，实际 ~276G）
x370	500G NVMe	2T HDD（挂载为 `hdd`）	仅 LVM，无 Thin Pool，无 VM

本文记录的操作：

在 x370 上移除 swap、缩容 root、创建 LVM-Thin Pool
将 pve 上的 VM-104 和 VM-110 跨节点迁移到 x370 的 LVM-Thin

1. 查看当前存储布局（x370 节点）

lvdisplay
vgdisplay
pvdisplay

输出：

  --- Logical volume ---
  LV Path                /dev/pve/swap
  LV Name                swap
  LV Size                8.00 GiB

  --- Logical volume ---
  LV Path                /dev/pve/root
  LV Name                root
  VG Name                pve
  LV Size                <456.76 GiB

  --- Volume group ---
  VG Name               pve
  VG Size               <464.76 GiB
  Free  PE / Size       0 / 0              # ← VG 已全部用完

  --- Physical volume ---
  PV Name               /dev/nvme0n1p3
  PV Size               464.76 GiB

pvesm status
cat /etc/pve/storage.cfg

当前只有 local（Directory 类型，路径 /var/lib/vz），无 local-lvm。

2. 确认 `local` 上的数据量

local 实际存储在系统根分区（/dev/pve/root）上：

df -h /
du -sh /var/lib/vz/*

x370 的系统盘非常干净——/var/lib/vz/ 下几乎无数据，root 仅占用 4.4 GiB。

结合 PVE 系统 + 更新 + 上传 ISO 临时空间，决定缩容 root 到 30 GiB：

缩容后布局：
  root       30 GiB     ← PVE 系统
  thinpool  ~434 GiB    ← swap 8G + root 释放的 ~426G

上传 ISO 时文件会先写入 /var/tmp（root 分区），30G 留出了约 16G 余量。

3. 移除 swap（PVE 运行中操作）

3.1 停用 swap

swapoff -a
swapon --show
# 无输出才算彻底关闭
free -h
# Swap 行应为 0

3.2 从 `/etc/fstab` 移除 swap 条目

cat /etc/fstab
# 输出：
# /dev/pve/root / ext4 errors=remount-ro 0 1
# UUID=AB21-9339 /boot/efi vfat defaults 0 1
# /dev/pve/swap none swap sw 0 0        ← 删掉这一行
# proc /proc proc defaults 0 0
# PARTUUID=... /mnt/pve/mHdd exfat nofail,... 0 0

sed -i '/\/dev\/pve\/swap/d' /etc/fstab

3.3 删除 swap LV

lvremove /dev/pve/swap

3.4 验证空闲空间

vgdisplay
# Free PE / Size 应显示约 8 GiB

4. Live 环境中缩容 `root` 并创建 Thin Pool

root 是运行中的根分区（ext4），无法在线缩容。以下步骤在 PVE ISO Debug Mode 的 Live 环境中完成。

4.1 进入 PVE Debug Mode Live 环境

① 从 PVE ISO 启动，选择：

Advanced Options
  ├── Install Proxmox VE (Graphical, Debug Mode)     ← 选这个
  └── Install Proxmox VE (Terminal UI, Debug Mode)   ← 图形黑屏则选这个

② 系统启动后会先进入 BusyBox 最小 shell（无 LVM 工具），直接退出：

exit
# 或 Ctrl + D

③ 退出后继续加载，会再次弹出 第二个 debug shell，此时 LVM 工具已就绪。

4.2 激活 LVM

vgscan
vgchange -ay
lvdisplay
# 应输出 /dev/pve/root

4.3 检查文件系统

e2fsck -f /dev/pve/root

4.4 缩小 ext4 到 30 GiB

resize2fs /dev/pve/root 30G

4.5 缩小 LV 到 30 GiB

lvreduce -L 30G /dev/pve/root

4.6 用空闲空间创建 Thin Pool

此时 VG 中的空闲空间 = swap 释放的 8 GiB + root 缩容释放的 ~426 GiB：

lvcreate -l 100%FREE -T /dev/pve/thinpool

验证：

lvdisplay
# 应看到：
#   /dev/pve/root       30G
#   /dev/pve/thinpool   ~434G

4.7 退出 Live 环境

exit
# 进入安装界面，选择 Abort → 拔掉 U 盘 → reboot

5. 重启回 PVE 并注册存储

5.1 验证 LVM

lvdisplay
# 应有 /dev/pve/root（30G）和 /dev/pve/thinpool（~434G）

5.2 向 PVE 添加 LVM-Thin 存储

pvesm add lvmthin local-lvm --vgname pve --thinpool thinpool

参数：

参数	必填	说明
`local-lvm`	✅	PVE 中显示的名称
`--vgname`	✅	卷组名，这里是 `pve`
`--thinpool`	✅	刚创建的 Thin Pool 名
`--content`	❌	默认 `images,rootdir`

验证：

pvesm status
# 应看到 local-lvm，类型 lvmthin

cat /etc/pve/storage.cfg
# 对应配置段：
# lvmthin: local-lvm
#         thinpool thinpool
#         vgname pve
#         content images,rootdir

6. 跨节点迁移前置：QEMU 版本对齐

跨节点在线迁移要求两节点 QEMU 版本一致。pve 节点的 PVE 版本较新（QEMU 9.x），而 x370 的 QEMU 还是 8.1.5：

pveversion
qemu-system-x86_64 --version | head -1

在 x370 上配置清华源并升级：

# 配置清华源（以 bookworm 为例）
cat > /etc/apt/sources.list << 'EOF'
deb https://mirrors.tuna.tsinghua.edu.cn/debian bookworm main contrib non-free non-free-firmware
deb https://mirrors.tuna.tsinghua.edu.cn/debian bookworm-updates main contrib non-free non-free-firmware
deb https://mirrors.tuna.tsinghua.edu.cn/debian-security bookworm-security main contrib non-free non-free-firmware
EOF

# 配置 PVE 社区源
cat > /etc/apt/sources.list.d/pve.list << 'EOF'
deb https://mirrors.tuna.tsinghua.edu.cn/proxmox/debian/pve bookworm pve-no-subscription
EOF

# 禁用企业版仓库（非订阅用户）
sed -i 's/^deb/#deb/' /etc/apt/sources.list.d/pve-enterprise.list 2>/dev/null

# 更新并升级
apt update && apt dist-upgrade -y

升级后可能看到以下提示：

Processing triggers for initramfs-tools (0.142+deb12u3) ...
update-initramfs: Generating /boot/initrd.img-6.8.12-25-pve
...
Removable bootloader found at '/boot/efi/EFI/BOOT/BOOTX64.efi',
but GRUB packages not set up to update it!

Run the following command:
echo 'grub-efi-amd64 grub2/force_efi_extra_removable boolean true' | debconf-set-selections -v -u
Then reinstall GRUB with 'apt install --reinstall grub-efi-amd64'

这不是错误，是 UEFI 可移动启动路径的一次性提醒。按提示修复即可：

echo 'grub-efi-amd64 grub2/force_efi_extra_removable boolean true' | debconf-set-selections -v -u
apt install --reinstall grub-efi-amd64

注意：升级前先解除 r8169 黑名单（避免失联）

如果 x370 使用 Realtek RTL8125 网卡并安装了第三方 r8125 驱动，apt dist-upgrade 升级内核后需要重新编译 r8125 驱动。

正确做法：升级后不要立即重启。此时旧内核仍在运行，r8125 驱动正常工作，网络未断开。先解除 r8169 黑名单再重启，确保新内核的备用方案就绪：

# 重启前解除 r8169 黑名单，让新内核回落为 r8169
sed -i 's/^blacklist r8169/#blacklist r8169/' /etc/modprobe.d/blacklist-r8169.conf
update-initramfs -u
reboot

重启后新内核加载 r8169 驱动，网络正常连接。通过 SSH 远程完成后续操作：

# 安装新内核头文件（此时 uname -r 为新内核版本）
apt install pve-headers-$(uname -r) -y
cd /root/realtek-r8125-dkms
./dkms-install.sh

# 恢复黑名单，禁用 r8169，让 r8125 接管
sed -i 's/^#blacklist r8169/blacklist r8169/' /etc/modprobe.d/blacklist-r8169.conf
update-initramfs -u
reboot

第二次重启后 r8125 驱动正常工作。

若已重启导致失联，接显示器键盘物理恢复后执行上述步骤。详见 realtek-r8125.md

7. 迁移 VM-104（在线迁移）

VM-104：384 GiB 虚拟大小，实际占用 ~150 GiB（Windows，Trim 后）。

x370 的 thin pool 当前还有 ~434 GiB 剩余空间，远超 VM-104 的虚拟大小，可直接在线迁移。

7.1 PVE GUI 迁移

x370 Web UI → 选择 pve 节点 → VM-104 → 迁移：

目标节点：x370
在线迁移（保持 VM 运行）
高级 → 目标存储：local-lvm

在线迁移使用 NBD（Network Block Device）传输数据，不加密，性能相当于纯 TCP 吞吐。

7.2 验证迁移完成

qm config 104
# scsi0: local-lvm:vm-104-disk-0,...
# efidisk0: local-lvm:vm-104-disk-1,...

lvs -a | grep thinpool
# Data% 应显示约 35%（150G / 434G）

7.3 配置 Discard、SSD 仿真

迁移完成后磁盘默认使用 raw 格式，需要开启 discard 和 ssd 仿真以支持 Trim：

qm set 104 --scsi0 local-lvm:vm-104-disk-0,cache=writeback,discard=on,iothread=1,ssd=1
qm set 104 --efidisk0 local-lvm:vm-104-disk-1,efitype=4m,pre-enrolled-keys=1

ssd=1 可以在磁盘创建后随时添加，不影响已有数据。Windows 重启后会自动识别为 SSD。

EFI 盘大小说明

EFI 盘虽然只有 528K，但 LVM-Thin 的最小分配单位是 4 MiB（PE Size）：

# 日志输出：Rounding up size to full physical extent 4.00 MiB
# 下面两种写法效果一样
lvcreate -V 528K -T pve/thinpool -n vm-104-disk-1   # 自动 round up 到 4M
lvcreate -V 4M -T pve/thinpool -n vm-104-disk-1     # 直接给 4M

8. Windows VM Trim 配置（VM-104）

LVM-Thin 的磁盘是精简置备的，VM 内删除文件后，需要通知底层存储释放已空闲的块，否则物理空间不会被回收。

8.1 检查磁盘配置

qm config 104

要求配置：

配置项	要求
总线类型	`VirtIO SCSI`
SCSI 控制器	`virtio-scsi-single`
Discard	`on`
SSD 仿真	`on`

8.2 Windows 内确认驱动

打开 设备管理器 → 存储控制器，应看到 Red Hat VirtIO SCSI pass-through controller。

如果不是，挂载 virtio-win.iso 更新驱动。

8.3 手动 Trim

管理员 PowerShell：

# 普通 Trim（日常回收）
Optimize-Volume -DriveLetter C -Verbose

# 全盘强制 Retrim（删除大量文件后立即回收，需足够 VM 内存）
Optimize-Volume -DriveLetter C -ReTrim -Verbose

全盘 Retrim 需要为磁盘全部空间构建位图，384G 磁盘约需 8G+ VM 内存，不足时报错 40002。

8.4 验证 Trim 状态

# Trim 是否启用（0 = 启用）
fsutil behavior query DisableDeleteNotify
# 输出：NTFS DisableDeleteNotify = 0

# 磁盘类型（应为 SSD）
Get-PhysicalDisk | Select-Object FriendlyName, MediaType, BusType
# MediaType 应为 SSD

8.5 备选：设置每周自动 Trim

Windows 通常自带磁盘优化计划任务（每周自动运行），不需要额外配置。如需手动添加备选任务：

schtasks /Create /SC WEEKLY /D SUN /TN "Trim C Drive" /TR "powershell.exe -Command 'Optimize-Volume -DriveLetter C -Verbose'" /RL HIGHEST /RU SYSTEM

8.6 PVE 上验证回收

lvs -a | grep thinpool

关注 Data%——VM-104 虚拟 384G 但 Data% 仅 ~35%，说明精简特性在正常工作。

lvs 的 LV Size 是虚拟大小（精简置备的上限），不代表物理占用。物理占用看 Data%。

9. 迁移 VM-110

VM-110：384 GiB 虚拟大小，实际占用 ~276 GiB（Windows，Trim 前）。

此时 x370 的 thin pool 已有 VM-104 占用 ~150G，剩余约 284 GiB。剩余空间小于 VM-110 的虚拟大小（384G），但大于实际数据（~276G）。

9.1 第一次尝试：在线迁移（被拒绝）

qm migrate 110 x370 --online --with-local-disks --target-storage local-lvm

PVE 拒绝执行——qm migrate 在发起前会检查目标 thin pool 的剩余物理空间是否 ≥ 虚拟大小，即使实际数据少得多也会拒绝。

9.2 第二次尝试：`qemu-img convert -W`（失败，数据损坏）

绕过在线迁移的限制，将 qcow2 文件拷贝到 x370 的机械硬盘后，直接导入到 LVM-Thin：

# ❌ 错误方案
qemu-img convert -p -W /mnt/pve/hdd/images/110/vm-110-disk-0.qcow2 /dev/pve/vm-110-disk-0

结果：Thin Pool 写穿至 100%，VM 能启动但系统卡顿、应用损坏。进入 Windows 后执行 Trim 报错：

VERBOSE: Invoking slab consolidation on (C:)...
Optimize-Volume : Failed

执行 chkdsk C: /F 发现文件系统错误（dirty bit 被设置），但修复后系统仍然异常——这不是普通的 dirty bit 问题，是 thin pool 写穿导致的数据错乱。

原因：-W 的含义是 out-of-order writes（乱序写入）：

官方文档：Allow out-of-order writes to the destination. This option improves performance, but is only recommended for preallocated devices like host devices or other raw block devices.

LVM-Thin volume 不是预分配设备，乱序写入导致 thin pool 的 chunk 分配碎片化，384G 虚拟空间被全部实际分配，物理空间耗尽后后续写入被丢弃。

场景	用 `-W`？
预分配设备（厚置备 LVM、物理磁盘）	✅ 乱序写入提升性能
LVM-Thin volume	❌ 不可用，碎片化写穿
管道传输（`\| ssh dd`）	❌ 不可用
qcow2 → qcow2	❌ 不需要

结论：往 LVM-Thin 写数据永远不要加 -W。

9.3 恢复：先备份 VM-104，再清理损坏数据

VM-104 已迁移到 x370 且正在正常使用，在清理前先将其备份到 x370 的机械硬盘上：

# 在 x370 上备份 VM-104 到本地机械硬盘
vzdump 104 --storage hdd --compress zstd
# 备份文件保存到 /mnt/pve/hdd/dump/

备份完成后，删除 x370 thin pool 中损坏的 VM-110 数据（同时清理 VM-104 以腾出空间）：

# 删除损坏的卷，释放 thin pool 空间
lvremove /dev/pve/vm-104-disk-0
lvremove /dev/pve/vm-104-disk-1

lvs -a | grep thinpool
# Data% 应降到正常水平

9.4 迁移策略调整

thin pool 总容量 ~434G，需迁入两个各 384G 的 VM。决定调整顺序：

先迁 VM-110（实际 ~276G，较大）→ 在线迁移
再迁 VM-104（实际 ~150G，较小）→ 备份恢复

这样 thin pool 在第一步后剩余 ~158G（434 - 276），第二步恢复备份时 VMA 会跳过空洞，~150G 实际数据写入后仍有盈余。

9.5 在线迁移 VM-110

VM-110 跨节点在线迁移到 x370：

qm migrate 110 x370 --online --with-local-disks --target-storage local-lvm

迁移完成后：

qm config 110
lvs -a | grep thinpool
# Data% 应约 63%（276G / 434G）

9.6 从备份恢复 VM-104

VM-104 的备份已在 9.3 中完成（在 x370 上备份到机械硬盘）。现在从备份恢复到 thin pool：

在 x370 节点 的 GUI 上操作：

Datacenter → x370 → 备份 → 选择备份文件 → 恢复到 local-lvm

VMA 恢复日志：

CFG: size: 658 name: qemu-server.conf
DEV: dev_id=1 size: 540672 devname: drive-efidisk0
DEV: dev_id=2 size: 412316860416 devname: drive-scsi0
  Logical volume "vm-104-disk-0" created.
  Logical volume "vm-104-disk-1" created.
map 'drive-efidisk0' to '/dev/pve/vm-104-disk-0' (write zeros = 0)
map 'drive-scsi0' to '/dev/pve/vm-104-disk-1' (write zeros = 0)
progress 1% (read 4123197440 bytes, duration 17 sec)
...
total bytes read  412317450240, sparse bytes 272608817152 (66.1%)
space reduction due to 4K zero blocks 1.45%

关键数据解读：

total bytes read  412317450240   → 虚拟 384 GiB
sparse bytes      272608817152   → 66.1% 被检测为空洞，跳过未写
zero block reduction              → 额外 1.45% 零块跳过
实际写入 thin pool ≈ 133 GiB     ← 远小于虚拟大小

9.7 最终结果

thin pool 物理: 434 GiB
VM-110 实际占用: ~276 GiB   ← 在线迁移
VM-104 实际占用: ~133 GiB   ← VMA 恢复（66.1% sparse 跳过）
━━━━━━━━━━━━━━━━━━━━━━━━━━━
实际总计:      ~409 GiB    ◀ 仍有 ~25 GiB 余量

两种方案对比：

	`qemu-img convert -W` ❌	VMA 备份恢复 ✅
稀疏检测	无（-W 乱序写入填满全部）	内置，恢复时自动跳过 66%+ 空洞
写入顺序	乱序（碎片化）	顺序（紧密排列）
Thin pool 空间利用	差，写穿 100%	优，仅 ~35%
数据一致性	数据损坏	高（VMA 含校验）

超额配置警告

创建 VM 的 thin volume 时可能看到：

WARNING: Sum of all thin volume sizes (<770.01 GiB) exceeds the size of thin pool
WARNING: You have not turned on protection against thin pools running out of space.

这是正常现象——两个 384G 的虚拟卷总和 768G 远超 434G 物理空间，这正是精简配置的工作方式。只要实际数据量之和不超过物理上限即可。

如果担心撑爆，可以启用自动扩容（需 VG 有空闲空间）：

# /etc/lvm/lvm.conf 设置：
#   thin_pool_autoextend_threshold = 80
#   thin_pool_autoextend_percent = 20

LVM-Thin 不支持缩容

若迁移后发现虚拟大小过大，不能像 qcow2 那样缩容：

存储类型	支持缩容	方式
qcow2 文件	✅	`qemu-img resize --shrink`
LVM 线性卷	✅	`lvreduce`
LVM-Thin volume	❌	不支持

只能新建小卷后复制数据：

lvcreate -V 300G -T pve/thinpool -n vm-110-disk-0-new
qemu-img convert -p /dev/pve/vm-110-disk-0 /dev/pve/vm-110-disk-0-new
qm set 110 -scsi0 local-lvm:vm-110-disk-0-new,discard=on,ssd=1
lvremove /dev/pve/vm-110-disk-0

10. 迁移后清理残留卷

迁移完成后，旧存储上的废弃卷可以删除。

# 确认无其他 VM 引用
grep -r "vm-104-disk-0\|vm-104-disk-1" /etc/pve/qemu-server/

# 删除残留卷
lvremove /dev/pve/vm-104-disk-0
lvremove /dev/pve/vm-104-disk-1

4MB 大小的卷通常是 EFI 盘，LVM-Thin 最小分配单位显示为 4M，属正常现象。

参考

Realtek R8125

Sat, 11 Apr 2026 00:00:00 +0800

Background

2.5G网卡，iperf3测速只有1G

Solution

1. 查询网卡及其驱动信息

# 查询网卡pci编号
lspci | grep RTL8125
# 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05)

# 查询网卡加载的驱动
lspci -s 06:00.0 -k
# 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05)
#         Subsystem: ASUSTeK Computer Inc. RTL8125 2.5GbE Controller
#         Kernel driver in use: r8169
#         Kernel modules: r8169

2. 安装`r8125`驱动

GitHub - awesometic/realtek-r8125-dkms: A DKMS package for easy use of Realtek r8125 driver, which supports 2.5 GbE.

apt update

apt install -y dkms pve-headers-$(uname -r) git

git clone https://github.com/awesometic/realtek-r8125-dkms.git

cd realtek-r8125-dkms

./dkms-install.sh

3. 禁用`r8169`驱动

# 检查是否仍在加载r8169驱动
lsmod | grep -i r8169
# r8169                 114688  0

# 禁用r8169驱动
sudo tee -a /etc/modprobe.d/blacklist-r8169.conf > /dev/null <<EOT
# To use r8125 driver explicitly
blacklist r8169
EOT

# 更新内核初始化文件 (让黑名单生效)
sudo update-initramfs -u

reboot

Reference

PVE 8安装 ReakTEK RTL8125B 2.5G网卡驱动 - 知乎

FAQ

1. `sudo update-initramfs -u` 告警

sudo update-initramfs -u

# output
update-initramfs: Generating /boot/initrd.img-6.8.12-18-pve
Running hook script 'zz-proxmox-boot'..
Re-executing '/etc/kernel/postinst.d/zz-proxmox-boot' in new private mount namespace..
No /etc/kernel/proxmox-boot-uuids found, skipping ESP sync.
# warning
System booted in EFI-mode but 'grub-efi-amd64' meta-package not installed!
Install 'grub-efi-amd64' to get updates.

Removable bootloader found at '/boot/efi/EFI/BOOT/BOOTX64.efi', but GRUB packages not set up to update it!
Run the following command:
# solution
echo 'grub-efi-amd64 grub2/force_efi_extra_removable boolean true' | debconf-set-selections -v -u

Then reinstall GRUB with 'apt install --reinstall grub-efi-amd64'

2. PVE内核升级后网卡驱动失效

apt dist-upgrade 升级 PVE 时可能升级内核，DKMS 安装的 r8125 驱动需为新内核重新编译。

正确处理方式（避免失联）

升级后不要立即重启。此时系统仍在运行旧内核，r8125 驱动正常工作，网络未断开。

利用当前网络，先解除 r8169 黑名单，确保新内核的备用方案就绪：

# 重启前解除 r8169 黑名单，让新内核回落为 r8169
sed -i 's/^blacklist r8169/#blacklist r8169/' /etc/modprobe.d/blacklist-r8169.conf
update-initramfs -u
reboot

重启后新内核加载 r8169 驱动，网络正常连接。通过 SSH 远程完成后续操作：

# 安装新内核头文件（此时 uname -r 为新内核版本）
apt install pve-headers-$(uname -r) -y
cd /root/realtek-r8125-dkms
./dkms-install.sh

# 恢复黑名单，禁用 r8169，让 r8125 接管
sed -i 's/^#blacklist r8169/blacklist r8169/' /etc/modprobe.d/blacklist-r8169.conf
update-initramfs -u
reboot

第二次重启后，r8125 驱动为当前内核编译，正常工作。

若已重启导致失联（物理恢复）

如果已经重启并断网（r8125 未为新内核编译、r8169 被黑名单屏蔽），需接显示器键盘物理恢复：

# 临时恢复 r8169 驱动
sed -i 's/^blacklist r8169/#blacklist r8169/' /etc/modprobe.d/blacklist-r8169.conf
update-initramfs -u
reboot

网络恢复后，执行上述正确处理方式中的安装头文件、重装 r8125 驱动、恢复黑名单、重启步骤。

也可以重启后选旧内核启动（GRUB → Advanced options），进去后网络正常，再为新内核重新编译驱动。

WNIC (Wireless network interface card)

Thu, 13 Jun 2024 00:00:00 +0800

WNIC(Wireless network interface card)

PVE

开启IOMMU

nano /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt pcie_acs_override=multifunction"

update-grub
reboot

设置虚拟化驱动

nano /etc/modules

vfio
vfio_iommu_type1
vfio_pci
# vfio_virqfd # no longer available in PVE 8

update-initramfs -u -k all

Reference

iStoreOS

Install

img2kvm

/mnt/pve/hdd/template/iso/img2kvm /mnt/pve/hdd/template/iso/istoreos-22.03.6-2024052410-x86-64-squashfs-combined-efi.img.gz 108 local

importdisk

qm importdisk 108 /mnt/pve/hdd/template/iso/istoreos-22.03.6-2024052410-x86-64-squashfs-combined.img.gz local

不可行，无法加载引导

FAQ

1. iStoreOS直通后重启，无线网卡变为未激活？

Defect Description

首次直通正常，能识别网卡

重启后，设备未激活

Solution

~~需要关机PVE => 拔掉网卡 => 启动PVE => 关机PVE => 插入网卡 => 启动PVE~~
关机PVE，完全断电后重启（目的是使无线网卡断电，怀疑被占用）
改用OpenWrt

OpenWrt

OpenWRT-PVE-AP-MT7922: guide to run OpenWRT on PVE with Access Point through m.2 wifi module MT7922

Setting up the OpenWrt disk

gunzip -k /mnt/pve/hdd/template/iso/openwrt-23.05.3-x86-64-generic-ext4-combined-efi.img.gz
# -k, --keep  keep original .gz file

qm importdisk 108 /mnt/pve/hdd/template/iso/openwrt-23.05.3-x86-64-generic-ext4-combined-efi.img local

Install wireless LAN card driver and firmware

opkg update
opkg install kmod-iwlwifi iwlwifi-firmware-ax210
opkg install kmod-mt7921e 
cd /lib/firmware/mediatek 
wget https://github.com/openwrt/mt76/raw/master/firmware/WIFI_MT7922_patch_mcu_1_1_hdr.bin 
wget https://github.com/openwrt/mt76/raw/master/firmware/WIFI_RAM_CODE_MT7922_1.bin
opkg install wpad-openssl
reboot

wget超时

使用rz

opkg install lrzsz
opkg remove lrzsz

FAQ

1. OpenWrt直通后重启，无线网卡is not active

首次直通

重启后

Solution

restart一次设备即可
设置开机脚本

System => Startup => Local startup

uci set wireless.radio0.disabled='1' 
uci set wireless.default_radio0.disabled='1' 
uci commit wireless
wifi reload
sleep 5
uci set wireless.radio0.disabled='0' 
uci set wireless.default_radio0.disabled='0' 
uci commit wireless
wifi reload

Configuration

1. 直通无线网卡

Configure

VM => Hardware => Add PCI Device

Raw Device

设备：MT7922
- 所有功能
- PCI-Express

Test

直通前

ip a

lspci -v # 查看pci占用状态

直通后

占用中

FAQ

1. No IOMMU detected

Proxmox VE(PVE)开启IOMMU功能实现硬件直通及直通错误解决_no iommu detected, please activate it.see document-CSDN博客

Solution

开启IOMMU，参考上文

2. 启动直通VM后，PVE文件系统失联

Defect Description

Reason

m2固态系统盘与无线网卡处在同一IOMMU组，被连带直通导致文件系统失联

Troubleshoot

查询IOMMU组

for d in /sys/kernel/iommu_groups/*/devices/*; do n=${d#*/iommu_groups/*}; n=${n%%/*}; printf 'IOMMU group %s ' "$n"; lspci -nns "${d##*/}"; done;

SOLVED - Filesystem corruption after PCIe passthrough | Proxmox Support Forum

【折腾踩坑记录】关于EXSI的网卡SR-IOV，以及X520DA2/SR2有什么区别的这档事。 - 哔哩哔哩

Solution

强制IOMMU分组

方法一. BIOS开启ACS(Access Control Services)

AMD CBS => NBIO Common Options => Enable AER Cap => ACS Enable

（华擎主板开启AER Cap后才会出现ACS）

Why so few IOMMU groups on ASRock X470 Taichi? - Operating Systems & Open Source / Virtualization - Level1Techs Forums

方法二. ACS补丁

# /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="... pcie_acs_override=downstream"

PCI直通 - Proxmox VE

3. 启动直通VM后，WebGUI失联，物理机终端有响应

Reason

开启ACS后，有线、无线网卡仍在一组，有线网卡被连带直通导致网络失联

Solution

# /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="... pcie_acs_override=multifunction"

LKML: Alex Williamson: [PATCH] pci: Enable overrides for missing ACS capabilities

PS

查看pve日志

journalctl -n 10

2. 连接无线热点

Network => Wireless => radio0 => scan

3. 测试

opkg update && opkg install curl
curl cip.cc
curl ip111.cn

P2V (Physical to Virtual)

Mon, 09 Oct 2023 00:00:00 +0800

P2V (Physical to Virtual)

1. `disk2vhd`导出虚拟磁盘

【操作步骤】勾选以下选项

a. Use Vhdx

b. Use Volume Shadow Copy

c. 系统盘、保留盘

FAQ

(1) `vhd`与`vhdx`区别

vhd：最大容量2T

vhdx：更新更快，最大容量64TB

(2) `Volume Shadow Copy`卷影复制的作用

快照，保证从复制开始到结束时，数据的一致性

2. 挂载`SMB`

【操作步骤】数据中心 -> 存储 -> 添加SMB/CIFS

FAQ

(1) 添加失败，错误提示

create storage failed: storage ‘smb’ is not online (500)

【解决方法】添加时取消勾选启动，从编辑入口进入再设置启用即可

CIFS: storage is not online (500) | Proxmox Support Forum

3. `vhdx`转换`qcow2`并导入

qm importdisk 100 /mnt/pve/smb/ark.vhdx local --format qcow2

FAQ

(1) 只能导入到`local-lvm`，而导入到`local`会报错？

storage local does not support vm images

【解决办法】数据中心 -> 存储 -> local的内容扩充支持磁盘映像

(2) `local`和`local-lvm`的区别？

佛西博客 - PVE的local和local-lvm (buduanwang.vip)

local-lvm属于lvm-thin类型，存储虚拟机时作为块设备，不能直接拷贝

local属于dir类型目录

lvs
cat /etc/pve/storage.cfg

【建议】qcow2足够优秀，且属于文件类型，不建议使用lvm-thin作为其存储底层

【方案】移除local-lvm并将空间并入local

a. 扩展`local`内容支持

数据中心 -> 存储 -> 编辑local -> 内容勾选所有

b. 删除`lvm-thin`

lvremove /dev/pve/data

c. 释放空间并入`local`

lvextend -rl +100%FREE /dev/pve/root

d. 检查空间

df -h

e. GUI移除`lvm-thin`

数据中心 -> 存储 -> 移除local-lvm

4. `UEFI`启动转换为传统`BIOS`引导

(1) 老毛桃官网下载完整版

ISO模式 -> 一键生成ISO文件

(2) 上传`ISO`镜像

local -> ISO镜像 -> 上传

(3) 挂载`ISO`

VM100 -> 硬件 -> CD/DVD驱动器 -> 使用ISO

(4) `winpe`操作

a. 启动`VM100`，选择`启动Win10 X64 PE`

b. 使用`分区工具`软件，删除主分区外的其他分区(包括系统保留分区)

c. 分区表类型从GPT转换成MBR

磁盘 -> 转换分区表类型为MBR格式

d. 将主分区设置为活动分区

右键系统盘 -> 激活当前分区

e. 保存更改

f. 将步骤2释放的空间合并到系统盘

右键系统盘 -> 扩容分区 -> 开始

FAQ

(a) 警告提示

无法修改Windows系统的BCD启动设置，调整Windows系统分区可能导致其无法启动，请进入到该系统中再执行调整命令

【操作】选择仍然调整，暂未发现异常

(5) 修复系统引导

使用引导修复软件，修复后使用分区工具检查主分区下是否已生成Boot目录和bootmgr文件

FAQ

a. 修复引导后能正常进系统，但卸载掉pe光盘后启动提示boot failed？

需按后文步骤(7)调整引导顺序

(6) 卸载`ISO`

(7) 调整引导顺序

虚拟机 -> 选项 -> 引导顺序 -> 勾选虚拟磁盘并调整排序为首位

5. IDE磁盘转换为SCSI

(1) 挂载virtio-win-0.1.240.iso

(2) 添加一个SCSI磁盘，大小不重要，只用于安装驱动程序

(3) 启动VM -> 设备管理器 -> 其他设备 -> 带感叹号的SCSI设备 -> 手动指向驱动目录vioscsi\2k22\amd64 -> 关闭VM

(4) VM硬件设置，删除临时的SCSI磁盘，将IDE磁盘更改为SCSI，cache选择write back，勾选discard

FAQ

a. 性能对比：`VirtIO SCSI`>`IDE`

`IDE`

`VirtIO SCSI`

6. 虚拟磁盘扩容

VM -> 点选磁盘 -> 磁盘操作 -> 调整大小 -> 填写增量大小 -> 重启VM

FAQ

（1）Windows扩容C盘，但是右边有一个恢复分区挡住？

Solution

使用CMD（管理员）删除恢复分区

diskpart
list disk # 查看所有磁盘信息
select disk X # X为包含恢复分区的磁盘编号
list partition # 查看磁盘上的所有分区
select partition Y # Y为恢复分区的编号
delete partition override
exit

7. `Intel E1000`网卡转为`VirtIO`

(1) VM-> 硬件 -> 网络设备 -> 模型Intel E1000改为VirtIO

(2) 启动VM -> 设备管理器 -> 其他设备 -> 带感叹号的以太网设备 -> 手动指向驱动目录NetKVM\2k22\amd64

FAQ

a. 性能对比：`VirtIO`>`Intel E1000`

`Intel E1000`

`VirtIO`

8. CPU类型性能对比

2690v4

host

avx2

kvm64

qemu64

x86-64-v3

aux2

1650v4

x86-64-v3

aux2

FAQ

(1) 为什么`host`反而跑分最低？

待研究

(2) `kvm64`和`qemu64`下的`cpuz`无`avx2`测试项可选？

可能因为cpu高级设置未勾选aux2特性

9. 内存`Balloon`

(1) 安装`Balloon`驱动

设备管理器 -> 其他设备 -> 带感叹号的PCI设备 -> 手动指向驱动目录Balloon\2k22\amd64

(2) 设置最小内存

VM -> 硬件 -> 内存 -> 高级 -> 最小内存

10. 直通`SATA`硬盘

pve硬盘直通

(1) 列出硬盘列表

ls -la /dev/disk/by-id/|grep -v dm|grep -v lvm|grep -v part

lrwxrwxrwx 1 root root 9 Oct 31 21:40 ata-WDC_WD20SPZX-22UA7T0_WD-WXA1E6962PFE -> ../../sda lrwxrwxrwx 1 root root 13 Oct 31 21:34 nvme-eui.00000000000000008ce38e03006b6199 -> ../../nvme0n1 lrwxrwxrwx 1 root root 13 Oct 31 21:34 nvme-KIOXIA-EXCERIA_SSD_71HA11F9K2V2 -> ../../nvme0n1 lrwxrwxrwx 1 root root 9 Oct 31 21:40 wwn-0x50014ee2670010fa -> ../../sda

nvme -> m2, ata -> sata

(2) 设置直通

qm set <vmid> --scsiX /dev/disk/by-id/xxxxxxx
qm set 100 --scsi1 /dev/disk/by-id/ata-WDC_WD20SPZX-22UA7T0_WD-WXA1E6962PFE

取消直通

qm set <vmid> --delete scsiX
qm set 100 --delete scsi1

11. WOL

Wake On Lan on Debian

(1) Install ethtool

apt install ethtool

(2) Checking the interface

ip a

enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP group default qlen 1000 link/ether 00:e0:4c:ad:e9:7e brd ff:ff:ff:ff:ff:ff

(3) Temporarily turn on `WOL`

ethtool --change enp5s0 wol g

(4) Check `WOL` status

ethtool enp5s0

Wake-on: g

g -> on, d -> off

(5) Permanently turn on `WOL`

a. Find ethtool directory

which ethtool

/usr/sbin/ethtool

b. Create `wol.service` in `/etc/systemd/system/`

[Unit]
Description=Enable Wake On Lan

[Service]
Type=oneshot
ExecStart =/usr/sbin/ethtool --change enp5s0 wol g

[Install]
WantedBy=basic.target

c. Enable service

systemctl daemon-reload
systemctl enable wol.service

12. KSM

調整 PVE 內建 KSM 機制參數

(1) Temporarily turn off `KSM`

系统 -> ksmtuned -> 停止

(2) Permanently turn off `KSM`

systemctl disable ksmtuned
systemctl status ksmtuned

(3) Permanently turn on `KSM`

systemctl enable ksmtuned
systemctl start ksmtuned

(4) 配置文件`/etc/ksmtuned.conf`

# Configuration file for ksmtuned.

# How long ksmtuned should sleep between tuning adjustments
# KSM_MONITOR_INTERVAL=60

# Millisecond sleep between ksm scans for 16Gb server.
# Smaller servers sleep more, bigger sleep less.
# KSM_SLEEP_MSEC=100

# KSM_NPAGES_BOOST=300
# KSM_NPAGES_DECAY=-50
# KSM_NPAGES_MIN=64
# KSM_NPAGES_MAX=1250

# KSM_THRES_COEF=20 # 剩余内存低于20%时激活ksm
# KSM_THRES_CONST=2048 # 剩余内存少于2048字节时激活

# uncomment the following if you want ksmtuned debug info

# LOGFILE=/var/log/ksmtuned
# DEBUG=1

(5) 实测效果与性能损耗

13. Swap

(1) Check the current Swap strategy

cat /proc/sys/vm/swappiness
# or
sysctl vm.swappiness
# vm.swappiness = 60 # 剩余内存低于60%时，启用Swap

(2) Temporary adjustment

sysctl vm.swappiness=0

(3) Persistent configuration

nano /etc/sysctl.conf

# Append at the end
vm.swappiness=0

sysctl -p # Reload configuration

14. Backup pve configuration

# storage, vm, cluster, user config
cp -r /var/lib/pve-cluster /mnt/pve/hdd/pveBackup
# restore
cp /mnt/pve/hdd/pveBackup/pve-cluster/config.db /var/lib/pve-cluster

# boot, modules config
mkdir /mnt/pve/hdd/pveBackup/{boot,modprobe}
cp /etc/modules-load.d/* /mnt/pve/hdd/pveBackup/modprobe/
cp /etc/default/grub /mnt/pve/hdd/pveBackup/boot/
cp /etc/modules /mnt/pve/hdd/pveBackup/
# restore
cp /mnt/pve/hdd/pveBackup/modprobe/* /etc/modules-load.d/
cp /mnt/pve/hdd/pveBackup/boot/grub /etc/default/
cp /mnt/pve/hdd/pveBackup/modules /etc/
update-grub
update-initramfs -k all -u

# network config
cp -r /etc/network /mnt/pve/hdd/pveBackup/
# restore
cp -r /mnt/pve/hdd/pveBackup/network/* /etc/network/
systemctl restart networking

FAQ

1. `VM`暂停和休眠的区别

【暂停】保持内存加载，但cpu分配为0

【休眠】内存保存到磁盘后释放

2. CPU-X 查询硬件信息

(1) cpu频率、占用、温度

(2) 内存频率、占用

apt install -y cpu-x
cpu-x # 会自动检查是否有显卡，无则启动基于文本的用户界面

3. 查询`CPU`温度（deprecated）

Debian 查看CPU温度

apt install lm-sensors -y
sensors-detect # all press Enter
sensors

4. 查询内存频率（deprecated）

硬件信息查询工具: lshw, dmidecode, hwinfo, CPU-X

(1) `lshw`

lshw -short -C memory

H/W path Device Class Description /0/0 memory 64KiB BIOS /0/56 memory 136GiB System Me /0/56/0 memory 32GiB DIMM DDR4 /0/56/1 memory 32GiB DIMM DDR4 /0/56/2 memory 32GiB DIMM DDR4 /0/56/3 memory 32GiB DIMM DDR4 /0/62 memory 896KiB L1 cache /0/63 memory 3584KiB L2 cache /0/64 memory 35MiB L3 cache

(2) `dmidecode`

apt install -y dmidecode
dmidecode -t memory | grep 'Speed:'

Speed: 2400 MT/s Configured Memory Speed: 2400 MT/s

FAQ

1. 数据是否准确？

【实测】5条内存只查出4条

【结论】不准确，可能是寨板魔改的原因

do I listen to dmidecode or the manufacturer?

5. 查询固态硬盘写入寿命

(1) Install `smartmontools`

apt install smartmontools -y

(2) Query `NVMe` device

ls /dev/nvm*

/dev/nvme0 /dev/nvme0n1p1 …

(3) Get smart info

smartctl -a /dev/nvme0

Data Units Written: 50,632,796 [25.9 TB]

Proxmox VE

Thu, 06 Oct 2022 00:00:00 +0800

Proxmox VE

安装`PVE`

下载PVE镜像
Rufus刻录，必须选择DD模式

PS：笔记本BIOS关闭安全启动模式
默认登录用户名root

`PVE`创建虚拟机

1. 显卡

默认，TODO

2. 磁盘

性能对比：VirtIO SCSI > SCSI > SATA > IDE

VirtIO SCSI

Linux原生支持
Windows系统，需安装驱动

硬件 > 添加CD/DVD驱动器 > 挂载 virtio-win-xxx.ios

3. 机型

决定虚拟机主板的硬件布局

Intel 440FX
Q35（较新，推荐），提供了虚拟PCIe总线，PCIe直通必选

4. BIOS

SeaBIOS
OVMF（较新，推荐），支持UEFI

5. 可信平台模块（TPM）

某些操作系统（例如Windows 11）要求将此类设备连接到计算机（无论是物理还是虚拟）

6. CPU

host模式（推荐），与主机物理cpu完全一致，拥有最佳性能，最大程度模拟其功能特性（CPU flags）
kvm64，具有较少CPU flag，缺少高级指令集（如MMX、AVX、AES），兼容性最好，适合实时迁移vm需求

Host vs Kvm64 ：虽然PVE允许切换虚拟机的CPU类型，但可能导致迁移后崩溃

7. 内存

设置内存容量 = 最小内存容量

此时分配固定容量内存
设置内存容量 > 最小内存容量

至少分配设置的最小容量内存，并在物理服务器内存占用率达到80%之前根据虚拟机需要动态分配内存，直到达到设置的最大内存分配量
最小内存容量（需开启ballooning，因此不适合win）
权重参数shares

示例：

总共4台虚拟机，3台HTTP服务器Shares=1000，1台数据库服务器Shares=3000

总共32GB内存，已使用16GB

剩余可自动分配内存：32*80%-16=9GB

数据库可分配内存：9*3000/(3000+1000*3)=4.5GB
ballooning选项

监控虚拟机的实际内存使用量
- Linux发行版默认安装了balloon驱动
- Windows系统，需手动安装驱动virtio-win-gt-x64.msi
  
  传闻旧驱动会占用不少cpu资源，影响系统性能，新驱动有所改善。若非内存紧张，不建议win开启balloon
  
  Fixed vs Variable Memory

FAQ

(1) 当所有虚拟机占用内存 > 物理内存，PVE会自动kill虚拟机

8. 网卡

性能对比：VirtIO > Intel E1000(千兆) > Realtek 8139(百兆)

桥接模式
NAT模式

VirtIO 手动安装驱动步骤：

设备管理器 > 其他设备 > 以太网控制器 > 右键更新驱动程序软件 > 浏览计算机以查到驱动程序软件 > 选择光盘自动搜索安装

FAQ

(1) PVE apt-get update 源失败

E: Failed to fetch https://enterprise.proxmox.com/debian/pve/dists/bullseye/InRelease  401  Unauthorized [IP: 51.79.159.216 443]
E: The repository 'https://enterprise.proxmox.com/debian/pve bullseye InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

原因：默认存储库为企业存储库，需要PVE 订阅密钥才能访问

解决方式：配置无订阅存储库

/etc/apt/sources.list

# 官方(慢)
deb http://download.proxmox.com/debian/pve bullseye pve-no-subscription
# 清华源
deb https://mirrors.tuna.tsinghua.edu.cn/proxmox/debian bullseye pve-no-subscription

(2) 使用清华apt软件源

/etc/apt/sources.list

# 默认注释了源码镜像以提高 apt update 速度，如有需要可自行取消注释
deb https://mirrors.tuna.tsinghua.edu.cn/debian/ bookworm main contrib non-free non-free-firmware
# deb-src https://mirrors.tuna.tsinghua.edu.cn/debian/ bookworm main contrib non-free non-free-firmware

deb https://mirrors.tuna.tsinghua.edu.cn/debian/ bookworm-updates main contrib non-free non-free-firmware
# deb-src https://mirrors.tuna.tsinghua.edu.cn/debian/ bookworm-updates main contrib non-free non-free-firmware

deb https://mirrors.tuna.tsinghua.edu.cn/debian/ bookworm-backports main contrib non-free non-free-firmware
# deb-src https://mirrors.tuna.tsinghua.edu.cn/debian/ bookworm-backports main contrib non-free non-free-firmware

deb https://mirrors.tuna.tsinghua.edu.cn/debian-security bookworm-security main contrib non-free non-free-firmware
# deb-src https://mirrors.tuna.tsinghua.edu.cn/debian-security bookworm-security main contrib non-free non-free-firmware

/etc/apt/sources.list.d/pve-no-subscription.list

deb https://mirrors.tuna.tsinghua.edu.cn/proxmox/debian/pve bookworm pve-no-subscription

LXC 硬件加速

Jellyfin LXC 硬件加速指南

1. 宿主机安装显卡驱动

英伟达驱动

# 显卡驱动前置依赖
apt-get update
apt-get install gcc make pve-headers-$(uname -r) -y

sh NVIDIA-Linux-x86_64-xxx.xx.run
# 报错：Unable to find the kernel source tree for the currently running kernel.  Please make sure you have installed the kernel source files for your kernel and that they are properly configured; on Red Hat Linux systems, for example, be sure you have the 'kernel-source' or 'kernel-devel' RPM installed.  If you know the correct kernel source files are installed, you may specify the kernel source path with the '--kernel-source-path' command line option
# 解决方式：必须安装对应内核的头文件
# apt-get install pve-headers-$(uname -r) -y

英特尔驱动（自带）

vainfo # 检查GPU解码支持
ls -l /dev/dri # 检查GPU设备是否加载

AMD驱动（待实践）

apt-get install mesa-va-drivers # 开源VA-API驱动
# 后续同iGPU

2. 宿主机设置驱动保持

驱动内核自启动

NVIDIA的驱动在有应用访问显卡的时候才加载内核和设备，但是用docker或者LXC访问宿主的显卡，驱动并不嫩感知。因此需要在系统启动时手动加载内核和设备。

/etc/modules-load.d/modules.conf
```
# /etc/modules-load.d/modules.conf
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
nvidia
nvidia_uvm
```

加载驱动

设置驱动内核加载时，执行加载什么驱动

/etc/udev/rules.d/70-nvidia.rules

# /etc/udev/rules.d/70-nvidia.rules
# Create /nvidia0, /dev/nvidia1 … and /nvidiactl when nvidia module is loaded
KERNEL=="nvidia", RUN+="/bin/bash -c '/usr/bin/nvidia-smi -L'"
#
# Create the CUDA node when nvidia_uvm CUDA module is loaded
KERNEL=="nvidia_uvm", RUN+="/bin/bash -c '/usr/bin/nvidia-modprobe -c0 -u'"

驱动持久化守护进程

如果长时间没有应用使用显卡，驱动程序会自动释放设备，因此需要驱动持久化软件。

git clone https://github.com/NVIDIA/nvidia-persistenced.git
cd nvidia-persistenced/init
./install.sh
systemctl status nvidia-persistenced # 检查进程状态

检查显卡驱动设备

root@pve:~# ls -l /dev/nv*
crw-rw-rw- 1 root root 195,   0 Jun 21 20:54 /dev/nvidia0
crw-rw-rw- 1 root root 195, 255 Jun 21 20:54 /dev/nvidiactl
crw-rw-rw- 1 root root 195, 254 Jun 21 20:54 /dev/nvidia-modeset
crw-rw-rw- 1 root root 236,   0 Jun 21 20:54 /dev/nvidia-uvm
crw-rw-rw- 1 root root 236,   1 Jun 21 20:54 /dev/nvidia-uvm-tools

3. LXC配置

GPU透传

/etc/pve/lxc/<container-id>.conf（GIDs要与上步查询id对应）

英伟达

lxc.cgroup2.devices.allow: c 195:* rwm
lxc.cgroup2.devices.allow: c 236:* rwm
lxc.mount.entry: /dev/nvidia0 dev/nvidia0 none bind,optional,create=file
lxc.mount.entry: /dev/nvidiactl dev/nvidiactl none bind,optional,create=file
lxc.mount.entry: /dev/nvidia-uvm dev/nvidia-uvm none bind,optional,create=file
lxc.mount.entry: /dev/nvidia-modeset dev/nvidia-modeset none bind,optional,create=file
lxc.mount.entry: /dev/nvidia-uvm-tools dev/nvidia-uvm-tools none bind,optional,create=file

英特尔、AMD（待实践）

lxc.cgroup2.devices.allow: c 226:0 rwm
lxc.cgroup2.devices.allow: c 226:128 rwm
lxc.mount.entry: /dev/dri/card0 dev/dri/card0 none bind,optional,create=file
lxc.mount.entry: /dev/dri/renderD128 dev/dri/renderD128 none bind,optional,create=file

LXC ssh

LXC默认不开启远程root登陆，需设置允许

/etc/ssh/sshd_config

PermitRootLogin yes # 允许root登录
PasswordAuthentication yes # 使用口令验证

systemctl restart sshd # 重启ssh服务生效
ip addr # 查看lxc ip地址，sftp上传驱动安装包
sh NVIDIA-Linux-x86_64-515.76.run --no-kernel-module  
# --no-kernel-module LXC无需安装内核模块，跳过
nvidia-smi # 检查lxc nv驱动

4. LXC Ubuntu安装Jellyfin

添加Jellyfin apt存储库源后，更新源失败：https证书过期

Err:5 https://repo.jellyfin.org/ubuntu focal Release 
Certificate verification failed: The certificate is NOT trusted. The certificate chain uses expired certificate.  Could not handshake: Error in the certificate verification

解决方法：

sudo apt-get install --reinstall ca-certificates

从Jellyfin存储库拉取安装包过慢

sudo apt install jellyfin

解决方法：设置apt代理

/etc/apt/apt.conf

Acquire::http::proxy "http://192.168.1.147:7890/";
Acquire::https::proxy "http://192.168.1.147:7890/";

# https需要代理到http，否则apt update报错
# Could not handshake: The TLS connection was non-properly terminated

Jellyfin不支持直接访问smb，改为Linux挂载smb即可

sudo mkdir /mnt/myFolder
sudo apt install cifs-utils -y
sudo mount -t cifs -o username=serverUserName //myServerIpAdress/sharename /mnt/myFolder/

设置开机自动挂载smb

/home/.smbAuth

user=smb
password=myPassword

/etc/fstab

//192.168.1.4/smb /mnt/myFolder cifs uid=0,credentials=/home/.smbAuth,iocharset=utf8,vers=3.0,noperm 0 0

测试

# 第一条执行无报错证明成功
sudo mount -a
sudo umount -a

iGPU 设置VAAPI硬解后，播放失败提示：

播放错误该客户端与媒体不兼容，服务器未发送兼容的媒体格式

报错日志：

[AVHWDeviceContext @ 0x564e13dff940] No VA display found for device /dev/dri/renderD128.
Device creation failed: -22.
Failed to set value 'vaapi=va:/dev/dri/renderD128' for option 'init_hw_device': Invalid argument
Error parsing global options: Invalid argument

原因： Jellyfin无直通设备的读写权限

解决方式：chmod 666 /dev/dri/renderD128

Jellyfin 中文字幕显示为方块
1. 下载 Noto Sans SC woff2 字体包
2. 解压出 NotoSansCJKsc-Medium.woff2 文件
3. 上传到LXC内 /usr/share/fonts/xxx
4. Jellyfin-控制台-播放，设置备用字体文件路径并启用

FAQ

LVM-thin 动态容量
虚拟机内的CPU速度不显示睿频？

VM CPUs–no turbo boost? | Proxmox Support Forum

Linux查询CPU实时频率

/proc/cpuinfo

watch -n.1 "grep \"^[c]pu MHz\" /proc/cpuinfo"
watch -n1 "grep \"^[c]pu MHz\" /proc/cpuinfo"

linux-cpupower

sudo apt install -y linux-cpupower
cpupower monitor

PVE CPU性能模式选择工具（默认即为Performance）
虚拟机克隆与备份的区别

克隆：常用于单pve平台跨存储克隆虚拟机

备份：可用于跨集群还原虚拟机

PVE on 南洋楹树洞

Fan Control on PVE

Fan Control on PVE

1. Load the Driver

2. Identify the Active PWM Channel

3. Create the Fixed-Speed Script

4. Set Up the systemd Service

5. Adjusting the Speed

PWM to RPM Mapping

Uninstall

PVE 磁盘健康检测

PVE 磁盘健康检测

一、快速查看磁盘状态

1. SMART 检测

实际输出：smartctl -A /dev/sda

二、SMART 数据解读

快查指令

三、深入扫描检测

1. SMART 长测试

实际输出

结果解读

后续操作

2. badblocks 全盘扫描

扫描结果

3. smartctl 与 badblocks 的区别

FAQ

为什么 SMART 差但 badblocks 无坏道？

badblocks 报出坏道的场景

综合判断

LVM 迁移至 LVM-Thin

LVM 迁移至 LVM-Thin

场景说明

1. 查看当前存储布局（x370 节点）

2. 确认 local 上的数据量

3. 移除 swap（PVE 运行中操作）

3.1 停用 swap

3.2 从 /etc/fstab 移除 swap 条目

3.3 删除 swap LV

3.4 验证空闲空间

4. Live 环境中缩容 root 并创建 Thin Pool

4.1 进入 PVE Debug Mode Live 环境

4.2 激活 LVM

4.3 检查文件系统

4.4 缩小 ext4 到 30 GiB

4.5 缩小 LV 到 30 GiB

4.6 用空闲空间创建 Thin Pool

4.7 退出 Live 环境

5. 重启回 PVE 并注册存储

5.1 验证 LVM

5.2 向 PVE 添加 LVM-Thin 存储

6. 跨节点迁移前置：QEMU 版本对齐

注意：升级前先解除 r8169 黑名单（避免失联）

7. 迁移 VM-104（在线迁移）

7.1 PVE GUI 迁移

7.2 验证迁移完成

7.3 配置 Discard、SSD 仿真

EFI 盘大小说明

8. Windows VM Trim 配置（VM-104）

8.1 检查磁盘配置

8.2 Windows 内确认驱动

8.3 手动 Trim

8.4 验证 Trim 状态

8.5 备选：设置每周自动 Trim

8.6 PVE 上验证回收

9. 迁移 VM-110

9.1 第一次尝试：在线迁移（被拒绝）

9.2 第二次尝试：qemu-img convert -W（失败，数据损坏）

9.3 恢复：先备份 VM-104，再清理损坏数据

9.4 迁移策略调整

9.5 在线迁移 VM-110

9.6 从备份恢复 VM-104

9.7 最终结果

超额配置警告

LVM-Thin 不支持缩容

10. 迁移后清理残留卷

参考

Realtek R8125

Background

Solution

1. 查询网卡及其驱动信息

实际输出：`smartctl -A /dev/sda`

2. 确认 `local` 上的数据量

3.2 从 `/etc/fstab` 移除 swap 条目

4. Live 环境中缩容 `root` 并创建 Thin Pool

9.2 第二次尝试：`qemu-img convert -W`（失败，数据损坏）

2. 安装`r8125`驱动

3. 禁用`r8169`驱动

1. `sudo update-initramfs -u` 告警

1. `disk2vhd`导出虚拟磁盘

(1) `vhd`与`vhdx`区别

(2) `Volume Shadow Copy`卷影复制的作用

2. 挂载`SMB`

3. `vhdx`转换`qcow2`并导入

(1) 只能导入到`local-lvm`，而导入到`local`会报错？

(2) `local`和`local-lvm`的区别？

a. 扩展`local`内容支持

b. 删除`lvm-thin`

c. 释放空间并入`local`

e. GUI移除`lvm-thin`

4. `UEFI`启动转换为传统`BIOS`引导

(2) 上传`ISO`镜像