Proxmox VE 9.2 深度教学｜存储篇

第一篇完成安装后，本例系统盘 /dev/sda 上已经有 local 与 local-lvm 两个存储入口。

前者主要保存 ISO、容器模板和备份文件，后者用于虚拟机磁盘；

四块 1.92 TB 数据盘仍需要规划。

与此同时，前期使用积累的 ISO 和备份已经使 local 使用率超过 93%。

数据盘如何组织、文件应该放在哪里，成为接下来需要解决的问题。

本篇沿用先讲原理、再做配置的写法，依次完成 ZFS 建池、local 空间优化、虚拟磁盘参数规划、磁盘迁移。重点不仅是点选哪个参数，还包括它解决什么问题、数据实际落在哪里，以及哪些调整需要提前迁移数据。

新虚拟机也可以直接把磁盘放在 zfs1，无须为了使用新池而先创建到 local-lvm 再迁移。

本篇环境

宿主机：Dell PowerEdge R740，PVE 9.2，系统识别内存约 503.2 GiB（内存条标称安装容量以硬件清单为准）。
系统盘：/dev/sda，采用 LVM 布局，保留 local 与 local-lvm。
数据盘：SK hynix HFS1T9G32FEH-BA10A × 4，单盘 1.92 TB（约 1.75 TiB），Non-RAID 直通，本例设备号 /dev/sdb 到 /dev/sde。
目标存储：zfs1，两个双盘 mirror；普通文件另通过 zfs1-iso、zfs1-backup 接入。
操作案例：已创建的 VM 100，openEuler 24.03 LTS SP1，示例虚拟磁盘 32 GB，迁移前位于 local-lvm。

一、数据盘存储规划与 ZFS 存储池配置

（一）ZFS 是什么：文件系统、卷管理与冗余保护

ZFS 是一套集成了文件系统与逻辑卷管理能力的存储系统。 PVE 使用的是 OpenZFS 实现，它既负责组织磁盘和管理空间，也能直接保存文件，或为虚拟机提供块存储。

在传统的 Linux 存储方案中，通常由 RAID 提供磁盘冗余，LVM 划分逻辑卷，再由 ext4、XFS 等文件系统保存数据。ZFS 将这些职责整合到一起：先将磁盘组织成存储池，再按需创建文件系统数据集或 ZVOL 块卷。

ZFS 的价值不只在于磁盘冗余，还在于对数据完整性和存储空间的统一管理。 它通过校验和检测数据损坏，在具备有效冗余数据时进行修复；采用写时复制（CoW）机制，更新时将新数据写入新的位置，快照则保留某一时点的数据状态。此外，ZFS 还提供克隆、压缩和配额等功能，便于日常管理。

不过，使用 ZFS 并不意味着自动获得磁盘冗余，能否承受坏盘取决于所选布局。

常见布局	实现方式与保护能力
单盘／无冗余条带	不提供整盘故障保护，成员盘失效可能导致整个池不可用。
Mirror（镜像）	多块磁盘保存相同数据。双盘镜像可容忍其中一块故障；多组镜像组成池时，每组都必须保留有效成员。
RAIDZ	使用分布式校验信息提供冗余，RAIDZ1、RAIDZ2、RAIDZ3 分别可容忍同组内任意 1、2、3 块成员盘故障。
dRAID	RAIDZ 的一种变体，同样提供一至三重校验，并支持分布式热备，以改善故障后的重建效率。

RAIDZ和dRAID的区别：RAIDZ 通常将故障盘的数据重建到一块替换盘或热备盘上，而 dRAID 可利用分散在多块磁盘上的热备空间并行重建，从而加快故障恢复。

需要注意的是，磁盘冗余主要用于应对硬盘故障，快照便于恢复此前的数据状态，两者都不能替代独立备份。如果整个存储池丢失或服务器损毁，仍需依靠池外备份恢复数据。

（二）先分清存储的分类与访问方式

在 PVE 的存储配置中，经常会看到目录（Directory）、LVM-thin（精简配置）、NFS、ZFS 和 CephFS 等名称，如下图所示。它们都可以用于提供存储，但有的侧重访问方式，有的负责管理底层磁盘，因此需要从不同角度理解。

注意：PVE 中的“添加存储”，是将本地存储或外部存储服务接入平台，供虚拟机和容器使用，而不是由 PVE 对外提供存储服务。

首先看 PVE 如何使用这些存储。 常见的访问方式分为文件级和块级：文件级存储通过目录和文件保存数据，虚拟机磁盘可以是一个镜像文件；块级存储则以逻辑卷或块设备承载虚拟机磁盘。

基本类型	数据如何保存	常见后端
文件级存储	以目录和文件的形式保存，虚拟磁盘通常表现为镜像文件	Directory、NFS、SMB/CIFS、CephFS
块级存储	以逻辑卷或块设备承载虚拟磁盘，通常不能直接保存 ISO 等普通文件	LVM、LVM-thin、iSCSI、Ceph RBD

其次看存储位于哪里，以及底层如何组织。 本地存储与网络存储，描述的是主机访问存储的路径：PVE 使用自身连接的 SSD，属于本地存储；通过 NFS 访问另一台服务器的共享目录，则属于网络存储。集中式与分布式描述的是存储系统的内部架构，即存储资源由集中设备承载，还是由多个节点协同提供。

这些分类可以同时成立。例如，一台服务器使用 ZFS 管理磁盘，再通过 NFS 向 PVE 提供共享目录。从 PVE 的角度看，这是通过网络访问的文件级存储；ZFS 则是远端服务器管理底层磁盘的方式。

存储是否共享，还需要单独判断。 共享意味着多台主机能够访问同一份存储资源，但共享块设备仍需要访问控制和协调机制，不能由多台主机随意同时写入。

在本教程中，ZFS 管理的是当前 PVE 节点直接控制的磁盘，属于本地存储。即使多个节点创建了同名 ZFS 池，并加入同一个 PVE 集群，各池的数据仍然彼此独立，不会自动变成共享存储。

Ceph 则由多个节点协同组织存储资源，在 PVE 中可以通过 RBD 提供共享块存储，也可以通过 CephFS 提供共享文件存储。因此，理解一种存储方案时，需要分别看它的访问方式、所在位置、内部架构和共享能力，而不能仅凭名称归类。

（三）为什么本教程选择 ZFS

结合前面的分类，本例的存储需求就比较清晰了：一台 PVE 宿主机配备四块 1.92 TB SSD，数据盘以 Non-RAID 方式直接交给操作系统管理，主要用于存放虚拟机磁盘，并提供磁盘冗余和数据完整性保护。

目前没有跨节点共享存储和节点级高可用需求，因此采用本地存储即可，无须引入 Ceph 的分布式架构和相应的运维工作。

本例选择 ZFS，主要是为了统一管理四块数据盘的冗余、数据校验和压缩。 LVM-thin 同样可以用于本地存储，第一篇安装后生成的 local-lvm，就对应系统盘上 pve 卷组中的 data 精简池。它主要负责存储空间的精简分配和逻辑卷快照，多盘冗余与数据完整性保护则需要结合底层方案另行设计。相比之下，ZFS 将这些能力整合在一起，更符合本例直接管理数据盘的需求。

将来扩展为多节点，也不意味着必须改用 Ceph。 各节点可以继续使用本地存储，也可以接入外部 NFS 或 SAN 共享存储。如果希望由多台服务器同时提供计算与存储资源，并通过节点间的数据冗余实现共享存储和故障恢复，再考虑 Proxmox 集成的 Ceph 超融合方案。官方要求此类集群至少配备三台服务器，并建议配置尽量一致；实际能承受哪些故障，还需结合副本策略、故障域、仲裁和剩余容量判断。

（四）理解磁盘、vdev、存储池与数据载体

ZFS 可以按“磁盘 → vdev → 存储池 → 数据集”理解，具体如下图所示

本例将四块 SSD 两两组成镜像 vdev，再共同构成 zfs1 存储池：组内保存数据副本，池在两组之间分配数据。池中的空间既可以用于创建文件系统、保存普通文件，也可以用于创建 ZVOL、作为虚拟机磁盘，两者都属于数据集。

需要注意，镜像保护建立在各组内部，本例任何一组镜像完全失效，都会影响整个池的可用性。

（五）四块盘选哪种 RAID 级别

本例使用四块 1.92 TB SSD，主要存放虚拟机磁盘。选择布局时，需要在可用容量、磁盘容错和随机读写性能之间取舍。PVE 界面中的 RAID 名称便于选择，而实际的冗余关系取决于磁盘如何组成 vdev。

下表按每块盘约 1.75 TiB 估算容量，未扣除元数据、保留空间和填充等开销，也不计压缩收益。

布局	理论容量	磁盘容错能力	主要取舍
RAID0：四盘条带	7.0 TiB	无容错能力	容量最大，但任意一盘故障都可能使整个池不可用
RAID1：四盘镜像	1.75 TiB	任意坏 3 块	四块盘保存相同数据，保护能力强，容量利用率低
RAID10：两组双盘镜像	3.5 TiB	任意坏 1 块；不同组可各坏 1 块	两组镜像分担负载，通常更适合虚拟机的小块随机 I/O
RAIDZ1：四盘单校验	5.25 TiB	任意坏 1 块	容量利用率较高，但故障恢复期间再坏一盘就可能丢失数据
RAIDZ2：四盘双校验	3.5 TiB	任意坏 2 块	双盘容错更稳妥，小块随机写通常不及两组镜像

本例最终选择 RAID10，主要看重多个虚拟机同时读写时的表现。 两组 mirror 可以并行承接负载，单盘故障后，也能从同组的健康磁盘恢复数据。这种布局比较符合本例对随机 I/O 性能和故障恢复方式的要求，但实际性能与恢复速度仍取决于业务负载和数据量。

RAID10 与 RAIDZ2 的理论容量相同，区别主要在于性能取向和容错范围。如果要求任意两块磁盘同时故障后仍可用，应选择 RAIDZ2。 RAID10 只有在两块坏盘分属不同镜像组时才能继续工作；同一组的两块盘全部失效，另一组无法补齐其数据。此外，RAIDZ2 用于小块虚拟磁盘时还存在校验与填充开销，因此两者最终可用空间不一定相同。

（六）清理旧磁盘信息的意义

第一篇已将四块数据盘配置为 Non-RAID，本例按操作系统能够分别管理这些磁盘的方式部署。正式清理前，仍需核对设备号、容量和序列号，确认目标确实是四块数据盘，并确认其中没有需要保留的数据；/dev/sdb 到 /dev/sde 是本次环境的设备号，不能照搬到其他服务器。

本例中的数据盘此前用于测试，仍保留旧分区信息。在“节点 → 磁盘”页面中，每块盘下面都有一个约 2.10 MB 的 sdX1 和一个约 1.92 TB 的 sdX2。

擦除之前，本例曾尝试创建 RAIDZ3。当时设备列表中出现了 /dev/sdb1、/dev/sdb2、/dev/sdc1 等八个分区，将这些分区全部选中后提交，任务最终失败。

从任务中的 zpool create 参数可以看出，本次误将四块磁盘上的八个分区作为成员设备，其中约 2.10 MB 的小分区容量不足，导致建池失败。因此，排查时应结合完整报错，先确认实际选中了哪些设备。

确认四块测试盘的数据均无须保留后，在“节点 → 磁盘”中选中整盘，点击“擦除磁盘”。确认框会列出磁盘类型、用途、大小和序列号，逐项核对后执行。

四块盘依次擦除后，本例列表中每块盘只剩一行，“用途”为“否”，GPT 为“否”。这是清理完成、尚未重新建池时的状态。

可以再通过命令行核对设备身份和残留分区：

1	lsblk -o NAME,SIZE,TYPE,FSTYPE,MODEL,SERIAL /dev/sd[b-e]

本例此时每块数据盘下面不应再列出旧分区。擦除会破坏原有分区和文件系统识别信息，应按破坏性操作处理；这里操作的是已经确认无须保留数据的测试盘，并不意味着所有显示有旧信息的盘都可以直接擦除。

（七）创建存储池并核对参数

进入 “节点 → 磁盘 → ZFS”，点击 “创建 ZFS”。本例使用以下配置，先确认参数，再提交任务。

参数	本例值	配置含义
名称	`zfs1`	指定 ZFS 池名；勾选“添加存储”后，本例同时创建同名 PVE 存储配置
RAID 级别	RAID10	四块盘组成两个双盘 mirror vdev
压缩	`on`	选择默认压缩算法；本例新建池启用 lz4 特性后，当前对应 lz4
ashift	`12`	对应 4096 字节的对齐与最小磁盘写入粒度
添加存储	勾选	自动注册 `zfspool` 后端，内容类型为磁盘映像和容器
设备	四块已清理的数据盘	本例选择 `/dev/sdb` 到 `/dev/sde` 的整盘条目，并再次核对容量与序列号

创建成功后，左侧存储列表出现 zfs1 (pve1)。

先查看池的实际布局：

1	zpool status zfs1

下面是本例运行后的状态记录，其中 scan 行反映最近一次 scrub 的结果，不是刚建池时必然出现的内容。

 pool: zfs1
 state: ONLINE
  scan: scrub repaired 0B in 00:00:14 with 0 errors on Sun Aug  9 00:24:15 2026
config:

        NAME                                          STATE     READ WRITE CKSUM
        zfs1                                          ONLINE       0     0     0
          mirror-0                                    ONLINE       0     0     0
            ata-HFS1T9G32FEH-BA10A_KN08N7077I0208L1M  ONLINE       0     0     0
            ata-HFS1T9G32FEH-BA10A_KN08N7077I0208L1N  ONLINE       0     0     0
          mirror-1                                    ONLINE       0     0     0
            ata-HFS1T9G32FEH-BA10A_KN08N7077I0208L1K  ONLINE       0     0     0
            ata-HFS1T9G32FEH-BA10A_KN08N7077I0208L1L  ONLINE       0     0     0

errors: No known data errors

重点核对两个 mirror 是否各包含两块预期磁盘、池与成员是否均为 ONLINE，以及 READ、WRITE、CKSUM 是否存在错误。设备列表中的持久化标识还可以用于与物理磁盘序列号对应。随后检查 PVE 是否已正确注册存储：

1 2	pvesm status zfs get compression zfs1

前者应能看到 zfs1 处于可用状态，后者用于核对根数据集的压缩属性。池状态正常与 PVE 存储可用是两层检查，二者都完成后，再继续为虚拟机分配磁盘。

二、local 存储空间优化与内容迁移

（一）为什么 ISO 默认上传到 local，而不能直接上传到 zfs1

第一章已经建立 ZFS 池，但打开 PVE 的 ISO 上传入口时，会发现 local 可以保存 ISO，local-lvm 和刚添加的 zfs1 却没有相同用途。

理解这个现象，需要同时看三个层次：底层资源能做什么、PVE 使用哪一种存储后端访问它，以及该存储配置启用了哪些内容类型。

ISO 在 PVE 的这条使用路径中，是一个由宿主机保存并管理的光盘镜像文件。 上传以后，PVE 需要把它写到后端支持的文件位置，随后让虚拟机的虚拟光驱读取它。这里的“ISO 镜像”与“虚拟机磁盘映像”是两种内容：前者在 PVE 中对应 iso，后者对应 images。不能因为两者的中文名称都有“镜像”，就认为支持 images 的存储也能上传 ISO。

本例采用 LVM 方式安装系统，默认的 local 是 Directory 类型存储，后端标识为 dir，路径指向 /var/lib/vz，内容配置包含 iso。因此，它既提供了文件保存位置，也允许 PVE 将其用作 ISO 存储。按照 Directory 后端的默认目录布局，上传的 ISO 实际存放在 /var/lib/vz/template/iso/ 下。local 本身只是 PVE 的存储 ID，并不是 ISO 专属的磁盘格式，也不是一个自动独立于系统盘的分区。

local-lvm 则通过 lvmthin 后端管理精简逻辑卷，zfs1 通过 zfspool 后端管理 ZFS 中的虚拟机磁盘和容器根目录。这两个后端支持的内容范围包括 images、rootdir，不包括 iso。

对虚拟机来说，zfspool 分配的 ZVOL 是可按块读写的虚拟磁盘载体，不是 PVE 用来接收普通文件上传的目录。即使客户机在这个虚拟磁盘中创建了文件系统，那也是客户机内部的文件空间，不会自动成为宿主机 ISO 上传列表中的存储。

因此，本例当前默认配置下只能把 ISO 上传到 local，原因是它是当前符合 ISO 存储要求的已配置后端，而不是 ZFS 无法保存 ISO 文件，也不是 ZFS 池缺少容量。

对于本来支持 ISO 的 Directory 存储，可以在配置中启用 iso 内容类型；

但对不支持这一内容类型的 zfspool，单纯修改名称或手工追加 iso 配置，并不能让它获得普通文件上传功能。

第一章提到，ZFS 除了 ZVOL，也能提供可挂载的文件系统数据集。因此，解决方法是在 zfs1 池内创建 zfs1/iso，挂载为宿主机目录 /zfs1/iso，再把这个目录注册为 PVE Directory 存储 zfs1-iso，并启用“ISO 镜像”内容类型。这样，底层数据依然由 ZFS 管理，PVE 则通过 Directory 后端保存和识别 ISO。下面把本例迁移前后的关系放在一起看。

PVE 存储 ID	后端类型	本例实际访问的资源	能否在本例中接收 ISO 上传
`local`	Directory（`dir`）	系统盘根文件系统中的 `/var/lib/vz`	可以，默认启用 `iso`；本章迁移结束后会取消该内容类型
`local-lvm`	LVM-thin（`lvmthin`）	`pve` 卷组中的 `data` 精简池	不可以，该后端不支持 `iso` 内容类型
`zfs1`	本地 ZFS（`zfspool`）	`zfs1` 池中供虚拟机和容器使用的数据载体	不可以，该后端不支持 `iso` 内容类型
`zfs1-iso`（本章新增）	Directory（`dir`）	文件系统数据集 `zfs1/iso` 挂载出的 `/zfs1/iso`	可以，注册时启用 `iso`，并确认数据集已挂载、存储可用

迁移后，一个 ISO 文件的默认存放位置会由 /var/lib/vz/template/iso/ 变成 /zfs1/iso/template/iso/，它占用的空间也会从系统盘根文件系统转到四块数据盘组成的 ZFS 池。变化的是文件所在的底层资源，以及 PVE 访问它的存储配置；并没有把原有 zfspool 后端转换成 Directory，两个后端可以同时使用同一池内各自管理的资源。

如需核对本机的实际配置，可以查看：

cat /etc/pve/storage.cfg
# 返回
dir: local
        path /var/lib/vz
        content backup,import,iso,vztmpl

lvmthin: local-lvm
        thinpool data
        vgname pve
        content images,rootdir

zfspool: zfs1
        pool zfs1
        content images,rootdir
        mountpoint /zfs1
        nodes pve1

其中 dir: local、lvmthin: local-lvm、zfspool: zfs1 冒号前的名称标识后端类型，冒号后的名称是存储 ID；path、pool、vgname 与 thinpool 等字段指向相应资源，content 列出本条配置允许的内容类型。启用了 iso 之后，还要满足当前节点可访问、存储处于启用且可用状态，以及用户具备相应权限等条件，才能正常上传。

我们也可以直接从刚建立好的PVE存储列表的“内容”一栏里直接看到区别，如下图所示，只有ID是local的存储类型是目录，内容包括了ISO镜像内容。

今后新增支持 ISO 的 NFS、CIFS 或其他 Directory 存储，也可以作为目标，ISO 并非只能保存在名为 local 的存储中。

（二）本例的空间占用问题

安装篇记录的空间问题：本例 local 存储运行两个多月后使用率 93.63%（100.86 GB 中已用 94.44 GB），里面堆的是 ISO 镜像和备份文件。local 是 PVE 的目录存储，本例默认路径为 /var/lib/vz，该目录位于 root 逻辑卷承载的根文件系统中。它与系统日志、软件包等内容共享根文件系统的空间；文件系统写满后，apt 更新、日志写入和备份任务都可能受到影响。

（三）比较三种处理思路

local 空间不足后，可以从三个方向处理：利用 pve 卷组的剩余空间扩大 root 逻辑卷；迁移 pve/data 中的数据后重建精简池，重新分配系统盘空间；或者把 ISO、模板和备份文件迁移到数据盘。

前两种方式调整的是系统盘的容量分配，第三种方式调整的是持续增长内容的存放位置，需要结合实际占用来源选择。

先检查 pve 卷组还有多少未分配空间：

vgs

本例输出如下：

1 2	VG #PV #LV #SN Attr VSize VFree pve 1 5 0 wz--n- <446.00g 16.00g

pve 卷组总容量约为 446 GiB，剩余 16 GiB 未分配空间。从技术上说，可以使用这部分空间扩大 root 逻辑卷及其文件系统，但本例 local 已使用 94 GB 以上，主要增长来自 ISO 和备份文件。扩容能够缓解当前压力，却没有改变这些文件持续写入系统盘的方式，因此只适合作为容量评估后的临时缓解措施。

第二种方式是重新分配 root 与 pve/data 的容量。local-lvm 是 PVE 存储 ID，底层对应 pve 卷组中的 data 精简池。若要从中腾出容量供 root 使用，不能把删除虚拟机磁盘后精简池内部增加的空闲空间，直接当成卷组的 VFree；本例讨论的方案需要先迁移其中的数据，再删除并重建较小的精简池。这涉及业务迁移和存储结构变更，为解决 ISO、备份占满系统盘的问题，通常没有必要采取这样的调整。

关于 LVM 扩容的具体原理与操作，可以参考我的另一篇文章：Linux在线扩容指南。

第三种方式更符合本例的实际目标：将持续增长的普通文件迁到四块数据盘组成的 ZFS 池上，让系统盘主要保留宿主机运行所需的内容。按照本章开头的分析，这一步需要为普通文件提供独立的 Directory 存储入口。

因此，本例在 zfs1 内创建独立的文件系统数据集，挂载为目录后再注册为 PVE Directory 存储。这样可以利用数据盘空间，分别管理 ISO 与临时备份的配额，也无须重新划分系统盘 LVM 布局。临时备份与虚拟机仍处于同一个池的故障范围内，正式备份目标应采用拥有独立存储的 PBS、NFS 或其他外部备份资源，第五章再说明具体安排。

（四）建议的做法：ZFS 池上建目录存储

处理 local 空间不足的问题，本例不再调整系统盘的 LVM 布局，而是把 ISO、容器模板以及临时备份文件迁移到新建的 zfs1。

具体做法是在 ZFS 池上分别创建 dataset，再通过 PVE 的 Directory Storage 接入。这样既能利用数据盘空间，也可以单独控制不同类型数据的容量。

首先处理 local 当前的高使用率。使用率已经超过 90% 时，应尽快停止向其中继续写入大文件，并清理确认不再需要的 ISO 和历史备份，或按下面的步骤复制到新位置、核对后删除源文件。本文以 80% 作为日常容量关注线，这是运维经验值，并非 PVE 的强制要求；具体还要结合剩余绝对容量和增长速度判断。

接下来在 zfs1 上分别创建 ISO的dataset：

1	zfs create -o quota=200G zfs1/iso

验证

zfs list -o name,quota,used,avail,mountpoint zfs1/iso

# 返回
NAME      QUOTA   USED  AVAIL  MOUNTPOINT
zfs1/iso   200G    96K   200G  /zfs1/iso

这里使用独立 dataset，主要有两个目的：一是可以分别查看空间使用情况，二是通过 quota 限制 ISO 和备份能够占用的最大空间，避免这些普通文件无限增长并挤占整个存储池。

需要注意，quota 只是限制上限，并不等同于为虚拟机磁盘预留容量。

在默认的 ZFS 挂载关系下，这两个文件系统数据集会分别挂载到 /zfs1/iso 。实际环境中建议通过上面的 zfs list 再确认一次 mountpoint，不要仅凭路径名称判断。

1
2
3

ls /zfs1/
# 返回
iso

然后进入 “数据中心 → 存储 → 添加 → 目录”，将 /zfs1/iso 注册为新的 Directory Storage。

其中 ID 填写 zfs1-iso，目录为 /zfs1/iso，内容选择“ISO 镜像”和“容器模板”，节点选择 pve1。“共享”保持不勾选，因为这个 dataset 只存在于当前节点。

PVE 的 Directory Storage 使用固定的目录结构：ISO 位于 template/iso/，容器模板位于 template/cache/，备份文件位于 dump/。这是 PVE Directory Backend 的标准布局。

此时我们开始将原来local中的iso文件直接迁移，避免重新再上传一次

1	cp -a /var/lib/vz/template/iso/. /zfs1/iso/template/iso/

此时我们在新的ID为zfs1-iso存储下会出现之前已上传的iso文件

确认无误后，再删除 local 中对应的旧文件。

最后进入 “数据中心 → 存储 → local → 编辑”，取消“ISO 镜像”“容器模板”和“备份”这些内容类型。如果仍需要在 local 中保存 snippets，可以只保留“片段（snippets）”。这样以后通过 PVE 界面上传 ISO 或创建备份时，就不会再默认写入系统盘。

完成以后可以通过下面几条命令检查结果：

系统盘使用率应明显下降，同时 ISO 和备份的空间占用已经转移到 zfs1。

三、虚拟创建过程中涉及的存储配置参数

存储池可用后，还要决定虚拟机如何使用它。包括系统安装盘，以及磁盘镜像的存储位置

本例安装 ISO 从 zfs1-iso 读取。可以看到所有的ISO已经从原来的local镜像上进行了迁移

新建虚拟磁盘时可以直接选择 zfs1，此时虚拟机的镜像保存在zfs1上

四、在线迁移虚拟机磁盘

接下来，我们将把正在运行的虚拟机 102（Ubuntu 24.04） 的磁盘，从原有的 local-lvm 在线迁移至新建的 zfs1 存储中。迁移过程无需关闭虚拟机，PVE 会完成磁盘数据复制及存储切换，虚拟机仍在当前节点上运行。

在 PVE 管理界面中选择虚拟机 102（Ubuntu 24.04），进入“硬件”页面，选中需要迁移的“硬盘（scsi0）”，点击“磁盘操作 → 移动存储”

再选择目标存储（如 zfs1），即可将磁盘从当前的 local-lvm 迁移过去。操作前应确认目标存储空间充足，并根据需要选择是否删除源磁盘；完成后，检查任务状态及磁盘的存储位置，确认迁移成功。

图中已勾选“删除源”，表示迁移成功后会删除原存储中的源磁盘，以释放空间；如需暂时保留源磁盘，可取消勾选。确认设置后，点击“移动磁盘”开始迁移，并在任务窗口中查看进度和执行结果。

本次测试中，迁移期间 ping 连通性正常；业务是否受到影响，还需结合应用响应及磁盘 I/O 指标判断